[Development] QtPim concerns
xizhi.zhu at nokia.com
xizhi.zhu at nokia.com
Sun Oct 23 07:56:39 CEST 2011
From: robin at viroteck.net [robin at viroteck.net] on behalf of ext Robin Burchell [robin+qt at viroteck.net]
> (dropping 'mikko' from CC, since I got his address wrong, I'll forward
> him a link to the thread)
Mika is added in CC ;)
> First up, thanks for your reply!
> On Sat, Oct 22, 2011 at 10:33 PM, <xizhi.zhu at nokia.com> wrote:
>> As far as I understand, we lost the commit history of all modules when
>> importing from QtMobility.
> Yes, looks that way. But it shouldn't have been impossible to keep
> that, right? Is it early enough that we can invest some time to try go
> back and do that *now*, given the advantages in terms of being able to
> find the context of why changes were made?
I don't think it's good if QtPim is the only module containing all the history, while
>> As of now, QtPim includes contacts, organizer and versit from QtM, and
>> future development should happen in QtPim, and only bug fixes are expected
>> in QtM.
> OK, thanks for the clarification.
>> Some tests are commented out just because they are failing, and we are
>> working to fix them. For sure, it's our target to get a higher coverage and
>> better quality.
> OK, as I suspected. What's your feeling on patches implementing new
> tests, for e.g. QDeclarativeContactModel, which is one of my first
> 'victims' with a few patches?
Mika and Cristiano are better contacts for Contacts API.
>> Currently, we are doing some refactoring / improvement for the APIs (mainly
>> limiting some unnecessary flexibility and reducing some complexity), so
>> probably it's further impacting our tests and merging from QtM.
> At least for the tests part, it shouldn't be. I think in an ideal
> world, you should be doing your best to follow your refactoring with
> test updates, and using those test results to make sure that nothing
> is breaking. I understand that this isn't strictly *always* possible,
> but that should be the exception, not the norm as much as possible.
> That's why, for instance, I'm talking about *creating* unit tests for
> QDCM before I even touch it. Because I don't want to break it.
Yes, that's true, and we're exactly trying the same. However, it's difficult for the
tests that are already commented out.
> It does complicate the QtM merge situation a bit more, yeah. I guess
> we'll just have to manage that, somehow.
We must ;)
Xizhi Zhu (Steven)
Software Engineer @ Qt Development Frameworks
Mobile: +358 (0)50 480 1247
More information about the Development