Releases in 3 months

[Aurélien Gâteau]

On Monday 08 July 2013 16:26:00 laurent Montel wrote:
> Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit :
> > Hi,
> > 
> > 2013/7/8 Àlex Fiestas:
> > > Now that kde-workspace and kdelibs are going to be frozen (which in
> > > theory
> > > means less work for everybody) I'd like to propose a new release
> > > schedule
> > > to be applied starting with 4.12.
> > > 
> > > Basically the idea is to cut testing time and compensate it by keeping
> > > master always in a "releaseable" state, now that two major components
> > > are
> > > frozen it looks like it is a good time to get used to it.
> > > 
> > > You can read all the proposal in:
> > > http://community.kde.org/KDE_Core/ReleasesProposal
> > > 
> > > Before sending this email I have checked with distro people, i18n
> > > people,
> > > other developers and almost all of them seemed to either like or be
> > > neutral
> > > about it (only one exception :p) so I hope that the proposal is not a
> > > complete disaster.
> > > 
> > > As its name indicates, it is a proposal, so please be constructive in
> > > the
> > > feedback, we can change as many things as we need.
> > 
> > I like the idea (from the Dolphin development point of view). Most of
> > the changes that went into master during the past months had already
> > been tested rather well before they were merged, and the remaining
> > regressions were found rather quickly by people who use the master
> > branch a lot. Therefore, it would have been nice if some of the
> > improvements could have been shipped to users sooner - quite a few
> > bugs that had been fixed in master (with patches that were IMHO too
> > intrusive for the 4.10 branch) months ago were reported again and
> > again.
> > 
> > @Laurent:you say that you have "a lot of features to implement", and
> > that this would not be possible with a shorter release schedule. But
> > wouldn't it be possible to implement some of the features for the next
> > version and the rest for the one after that?
> > 
> > If you think that you
> > need more time to stabilize a feature in the master branch, then maybe
> > developing the feature in a separate branch and merge it once it's
> > finished might be a good idea?
> 
> No it’s not a good idea because nobody tests branch you can see pb that we
> had when we merge akonadi branch (last big changes).

It is true that we have a problem with getting people to test branches. But 
this problem is independant from the release schedule: I believe developing in 
branches is a good way to work, no matter if releases are created every 3 or 6 
months.

Having said so, I think Akonadi is a bad example because:
- It was a huge change, quite the equivalent of a rewrite
- It was affecting personal data

When we develop a new feature and want to get more testing, we need to get 
people to know about it so that they are interested in testing it. If I create 
a feature but nobody knows about it, it won't get much testing, whether it is 
in master or on a topic branch.

If the feature is developed in master, I have to be careful not to introduce 
any regression in the existing code before I push any commit, I cannot rely on 
my group of interested people to spot it because they can't test my work 
before it reaches master. At feature-freeze time, if my feature is not ready, 
it is often impossible to revert because the history is mangled with the rest 
of the work done in master. Furthermore I don't want to revert because it 
would make me wait for 6 months!

If the feature is developed in a topic branch, I should still be careful not 
to introduce regressions, but I have an extra safety net before it reaches 
master and can affect people who are not involved in testing my feature. 
Having it in a branch also gives me a way out: if it turns out the feature is 
not ready in time for release N, it is possible for me to revert the 
"integration commit" (because it has been merged in with "--no-ff" [1]) and 
post-pone the feature for the next release. I am still frustrated, but it's 
not so bad with this new schedule because release N+1 is only 3 months away.


I like this new schedule because it should reduce the more-or-less 
subconscious behavior of "let's commit this in master before feature-freeze, 
it's half broken but I need to commit it now otherwise Albert^Wthe release 
team is going to (rightfully) yell at me! it's no problem I have more than 
enough time to fix it before release" (famous last words...)

Aurélien

[1] http://nvie.com/posts/a-successful-git-branching-model/ , section 
"Incorporating a finished feature on develop"