[Development] QtPim concerns

Robin Burchell robin+qt at viroteck.net
Sat Oct 22 23:53:13 CEST 2011


(dropping 'mikko' from CC, since I got his address wrong, I'll forward
him a link to the thread)

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?

> 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?

> 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.

It does complicate the QtM merge situation a bit more, yeah. I guess
we'll just have to manage that, somehow.



More information about the Development mailing list