Releases in 3 months

[Aurélien Gâteau]

On Monday 08 July 2013 23:08:29 Ingo Klöcker wrote:
> On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote:
> > 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
> 
> Akonadi was developed in a branch. Okay, this branch was called master
> and the stable branch was called KDE 4.4 (IIRC), and, of course, this
> wasn't nice for people who built everything from master. But we tried to
> communicate very clearly that master was not to be used for anything
> expect for KDE PIM development.
> 
> And, of course, we did consider using a proper branch, but then we would
> have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given
> that we didn't and still don't have enough people to even maintain the
> Akonadi branch (aka master) I still think that this decision was the
> only sensible one. The only feasible alternative would have been the
> deletion of master until the first Akonadi-based alpha release.

Don't get me wrong: I did not write this as a grief against the way Akonadi 
was developed. I just wanted to highlight that nowadays most feature branches 
are less frightening to test than an Akonadi port, because they are much 
smaller, so you can expect more people to dive in and test it.

Aurélien