[Development] QtPim concerns

[xizhi.zhu at nokia.com]

Hi,

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
others don't.


>> 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 ;)


> thanks,

> Robin

================
Xizhi Zhu (Steven)

Software Engineer @ Qt Development Frameworks
Nokia

Mobile: +358 (0)50 480 1247