[Development] [Releasing] Including QTimeZone in Qt 5.1

John Layt jlayt at kde.org
Wed Feb 27 22:05:32 CET 2013


On Wednesday 27 Feb 2013 10:26:51 Oswald Buddenhagen wrote:
> On Tue, Feb 26, 2013 at 04:12:07PM -0800, Thiago Macieira wrote:
> > On terça-feira, 26 de fevereiro de 2013 22.42.31, John Layt wrote:
> > > On Wednesday 20 Feb 2013 16:16:55 Thiago Macieira wrote:
> > > > For 12 commits, I'd just submit straight to dev.
> > > 
> > > Would you prefer it squashed to one big commit, or keep the platform
> > > backends separate commits?
> > 
> > I prefer separate commits, but Ossi generally disagrees.
> 
> in this broadness, this statement most certainly contradicts reality. ;)
> 
> there are two question clusters to answer here:
> - does it actually buy us anything to split this up?
>   - are these changes logically distinct? (i'm not convinced)
>   - is it easier to review? (not really - the parts are pretty well
>     separated)
>   - is undoing these additions separately a plausible scenario?
>     (unlikely)
> - does it hurt to split it up?
>   - is the frontend even testable without a backend? if not, then adding
>     at least one halfways generic backend together with the frontend
>     would be required to satisfy strict atomicity. you could cheat and
>     make the tests QSKIP if no backend is found, but you shouldn't do that
>     if running without backends is not actually a supported case.

Some good points.  I've decided to squash the default UTC backend and basic 
tests into the first commit so we have a fully working and tested albeit 
limited implementation with that commit.  I'll keep the platform backends and 
their specific tests separate so they're easier for the Win and Mac 
maintainers to review without the noise of the rest of the reviews, and for me 
to fix the inevitable bugs in them.

That reduces the QTimeZone commits to 5, and 1 for the QDateTime changes.

Thanks!

John.




More information about the Development mailing list