[Development] On the effectiveness of time based releases

[Frederik Gladhorn]

Mandag 24. februar 2014 13.17.58 skrev Giuseppe D'Angelo:
> Hello,
> 
> right next to the discussion about the branching model, I'd like to
> propose a discussion about the time based releases. In particular,
> both for 5.2 and for 5.3 the model has IMO failed, in that features
> that were considered "too good to be missing" were rushed in at the
> last second (or even merged in stable after the actual dev->stable
> merge did happen).

There is always a trade-off, we aim for perfection but also need to advance Qt 
as product.

> Some of those features then either caused regressions (... ok,
> that's what betas are for, although it may also be a symptom of poor
> testing in order to get the feature in), or are highly debatable
> from an API / technical point of view (which is even worse, because
> we can't change APIs or behaviour once we release). (*)

Yes, I feel we haven't reviewed new public API in a sensible way. Any 
suggestions how to make this work? In the Nokia days (and earlier of course) 
there were long long sessions discussing API and perfecting it. In a sense 
it's really hard to achieve the same over IRC and mail, but maybe we should 
come up with a better way of dealing with this.

> The current branch guidelines [1] say
> 
>  > dev: unfrozen branch, containing alpha-quality code
>  > that is ready to go into beta testing at any time
> 
> "Alpha quality code" still means that the code respects *ALL* of the
> following:
> 
> *   for any "major" feature, and any metric of "major" (wide
>      audience, complex implementation, deep impact for users, ...),
>      the feature got through a round of public debate on the ML
>      (still, lazy consensus applies);
> 
> *   has gone through a round of public API review (possibly outside
>      of gerrit. on gerrit it would do if it also comes with
>      exhaustive example code);
> 
> *   is carefully documented;
> 
> *   it has proper autotests (if appliable);
> 
> *   strictly follows Qt coding guidelines;
> 
> *   compiles on all reference platforms;
> 
> *   works on all reference platforms;
> 
> *   possibly, it has been tested by third parties who got involved
>      in the above processes.
> 
> Code missing ANY of these does not belong to dev. It belongs to a
> working branch (under CI) which can be rebased on dev and merged
> when the code is ready. It certainly not belongs to stable.

Agreed.

> Unfortunately, it looks to me that time based releases seem to
> encourage developers to try to rush to get their feature in. This
> may be an indication that we'd like to move to feature-based
> releases. Which I have nothing against, except that we then need to
> discuss, agree and change our own rules.

I think we should not give up on time based releases. We will never make the 
exact cut off dates is my feeling and need some wiggle room. The time based 
scheme is there to help us, not make us slaves of the schedule.

I'll also readily admit that we haven't reached the state where our releases 
go as smooth and predictable as we'd all like, but we're learning and 
improving as we go along. Inside the community and inside Digia where a lot of 
the work for making a release happens.

Going back to a feature based release cycle makes it impossible to get 
everyone aligned, Qt as a project has grown too big with too many modules to 
make that possible. We want to make releases of all modules at the same time 
since it's less work and we also have too many interdependencies between 
modules to make it feasible.

For me it feels like the time based releases are a blessing, we just need to 
get used to them a bit more. I would have liked to have a few more patches in 
Qt 5.3, but then that is the same with every release :)


> [1] http://qt-project.org/wiki/Branch-Guidelines
> 
> (*) I'll deliberaly keep the technical discussion outside of this
> thread and start new threads to address the issues. This is about
> the policy.

-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com