Fwd: KDE Frameworks Release Cycle

Martin Gräßlin mgraesslin at kde.org
Wed Apr 30 09:51:29 UTC 2014

On Wednesday 30 April 2014 11:35:54 Àlex Fiestas wrote:
> On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
> > For non-rolling distros, at some point you have to stop and release. A mix
> > of new features and bug fixes aren't going to be allowed in.
> > 
> > We (Kubuntu) have been delivering KDE SC point releases as post-release
> > updates to our users for most (maybe all) KDE4 releases. That's over with
> > KF5.
> > 
> > We'll, I guess, have to settle for cherry picking fixes and doing our
> > best.
> You might not know this but most developers don't do proper testing in the
> stable branches because the cost of having master and stable environments
> and doing testing in both branches for each fix is too much, we simply
> don't have the manpower for that.
> History has shown this maaaany times, we have done point releases that were
> horrible quality-wise because nobody was testing them. The stable branches
> have virtually no users.

Just a note: consider watching David's, Vishesh's and my Akademy talk from 
last year. I discuss the problem with stable releases in detail and the mess 
we created in the past.

> So, I honestly think that if we work together you can do a better work
> cherry- picking than we can. Also we should develop tools to make your life
> easier.

Actually I think there is nothing wrong with having something like an "LTS" 
release which is maintained by the distros. I recently read that Ubuntu picked 
up maintenance of the Linux Kernel they are using. I think that the same could 
be done here, just that it might need tighter integration from the distros. 
E.g. thinking about which version would work well for the next openSUSE and 
Kubuntu release. Personally from an upstream position I would love to see 
stronger collaboration between our stakeholders.

Also what should be quite obvious: asking the maintainers whether the fixes 
are backportable should always be possible.

-------------- 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/release-team/attachments/20140430/a1e44ec3/attachment.sig>

More information about the release-team mailing list