Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Àlex Fiestas]

On Wednesday 30 April 2014 13:44:50 Raymond Wooninck wrote:
> > So, you will not simply update to 4.14.X but instead do cherry-picking of
> > the bug fixes? Because that would be the same with Frameworks.
> 
> You got that one wrong :)  We push the 4.14.x release as a full maintenance
> update. So if 13.2 is shipped with 4.14.0, then 4.14.1 is pushed as
> maintenance update as soon as it becomes available.  This is no longer
> possible with Frameworks.
It is, you (as in opensuse) just have to get over the drama of having small 
features in on each release.

Let's try to analyze a bit why some distros have this panic to new versions 
containing features (when it comes to KDE).

For the longest amount of time in KDE4 has been releasing as a whole doing a 
big release every 6 months. This had the following impact of how things were 
developed:
-People would develop super big features, some times even new apps.
-People would push last minutes features to avoid the freeze (if you don't get 
in then you had to wait up to 8 months for next release).
-People would merge things that are not ready because if something is wrong a 
bit was not a big deal (you had months to amend it).
-Each release contained a lot of code changed.

These things (plus others less important imho) produced that the first release 
(X.X.0) would suck and it wouldn't be until X.X.2 that it will become stable 
(at which point developers would be already working on X.X+1).

So this is our attempt to improve quality:
-Develop really small features (if a feature is big, split it), put them in 
master the moment they are ready.
-No freezes and short release cycles, if you fail to put your thing on the 
release X you can do it one more after. No big deal.
-Merging things that are not unittested and/or without review will not be 
allowed.
-Make smaller releases, less changes less possibility of messing it up.

This workflow (or similar) is being used successfully in a lot of other free 
software projects that are as big as we are. It has helped them to increase 
quality and to make releases more stable. I believe it will allow us to do the 
same.

So, I understand that for big releases you wouldn't trust us on "no 
regressions", but please take into account that these releases will be a 
completely different monster.

Finally, could you (or any packager with similar concerns) explain to me which 
reasons (apart from policy) would make you not comfortable releasing this?
> > The difference is that you will do proper testing with all the QA in place
> > on each distros, we don't have such thing "upstream" beyond the tests.
> 
> But we would be doing QA on "older" KF5 releases and not at something for
> which we would still receive bugfixes.
Well, again take into account the size of these releases will be super small. 
In fact most of the frameworks (based on kdelibs experience) will not even 
receive new features most of the times, meaning that if you really really want 
to "not release features" you should be able to backport most of the fixes.

Also, we can enable the tools so you can know which fixes should be backported 
an which fixes shouldn't, for example a "BACKPORT" keyword in the commit or 
some similar system.

Cheers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140430/f8eb1e8c/attachment.sig>