[Development] On the effectiveness of time based releases

[Olivier Goffart]

On Monday 24 February 2014 13:17:58 Giuseppe D'Angelo wrote:
> 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).
> 
> 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). (*)
>
[...] 
>
> 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.
> 
> 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 am not sure what was exactly the problem in question you are referring to. 
If I understand correctly you believe that some code will go into Qt 5.3 
without being ready? (And that would have been beneficial to wait?)
The good news is that 5.3 has not been released yet, that feature can still be 
rolled back and that we got time to stabilize because Qt  « follow a hybrid 
time- and quality-based schedule » [1].
Before merging a feature the maintainers consider if yes or not the feature is 
ready for integration. If bad decisions are made, I don't think the "time-
based" releases have anything to do with that.



I think what has failed is the branching scheme:
"dev" / "stable" / "release".
We've tried this model for almost 3 releases and I would not say it worked.
It is more confusing than it helps.

I'd say let "dev" be called "master" like in every other project. And let 
"stable" be called "5.3" and "release" would be "5.3.0" because that's what it 
is.
When you want to submit a patch to gerrit and have to choose the branch, are 
you asking yourself: "should this patch go to dev or to stable?" or "should 
this patch for 5.3.x?"
So let's call the branch by their name and avoid the confusion.

Also let's have a branching window instead of a branching point. (i.e. have 
about a week after 5.x is branched during in which we still merge master in 
5.x.) That way we don't have race condition when submitting patches around the 
branching point, and we work around the limitation of gerrit of not being able 
to re-target to another branch.


[1] http://qt-project.org/wiki/Branch-Guidelines

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org