Releases in 3 months

[Ingo Klöcker]

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.

But all of this is stuff from the past. When we do Akonadi 2 ;-) we'll 
probably choose a different path.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130708/031c2150/attachment.sig>