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. Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team