hi ... it would be interesting to see a true cost/benefit analysis using real data of the benefits of the monthly bug fix releases.
in support of what Kevin is going after here: the monthly bugfix releases sound awesome on paper, but they don't always work. i've seen significant regressions in recent releases due to patches being backported with poor judgment, resulting in bug reports by users. this has also happen less recently, of course. it just simply _happens_. the monthly bug fix releases are NOT a panacea, they are just better than not doing anything at all for N months. this is something everyone ought to accept: it is reality. there is, however, a high rate of success for backported patches. the overwhelming majority do what they are supposed to. that is also reality. the actually interesting question is how many of those successful patches are so important that users need them now versus 6 months from now, and how bad regressions are. those measurements are not objective. they require some values to be expressed and applied to them. some may not think the odd regression is a big deal, some might think it is THE thing to avoid. quantity, quality, flow, reliability, etc... keeping in mind that this thread is not about Plasma or any of the KDE applications, the expectations and goals of the *Frameworks* developers _and_ users (app devs) are probably unique in this case. the Frameworks team would probably do everyone a favor by clearly stating their goals in terms of stability expectations and rate of change so we know how to weight the different outcomes that happen. anyways, on to Scott's (re-)proposal: On Tuesday, May 20, 2014 09:45:36 Scott Kitterman wrote: > This or something very like it was already suggested by someone else, so I'm > not claiming this as my idea, but I think a reasonable compromise would be > something like: > > - Monthly feature releases as proposed. > > - Select one release every 6 months as long term support (I'd suggest > March/September) which has a stable branch. has anyone sat down and done a proper "best time" measurement? 6 months is thrown out there probably because we know 6 months and certain distributions have made it a popular number. but what is the *actual* largest number that reaches as many distribution releases as possible? in any case, having long term stability branches is not the worst thing in the world imho and is a good idea. it's not popular amongst many developers, admittedly. i tried to advocate for this for both kdelibs 4.7 and kde- workspace 4.11 .. the former was rejected, and problems ensued; the latter was adopted and it has worked very nicely, though there was some degree of skepticism. so that's a hump to climb over which Scott is evidently hitting. as a user, i'd love to see such stable branches, fwiw, and i'd be just happy with a single new kdelibs long term release every year. 6 months feels a bit like luxury. ("long": you keep using that word, but i don't think it means what you think it means. ;) > - Developers backport "safe" fixes to the stable branch. this is a critical issue. not enough developers who backport are able to accurately judge this consistently enough. many reasons exist for this (tooling, testing, experience, blah blah) but reasons are just reasons -> if we rely on developers to backport safe fixes, it's going to break (because it does already) and that will defeat one aspect of what Kevin is trying to achieve: higher quality there are ways around this, however! it is not uncommon in other projects for people to "own" a long term branch and only they merge in patches. period. that person needs to be disciplined (so they don't just become a rubber-stamp bureaucrat), but this is one area where having a bottleneck is actually good: you don't WANT lots of changes. you WANT a slow rate of change. you WANT every change to be justified. for it to work that person(s) needs to be able to say "no". they also need to be allowed to say "no". if they won't say "no" when necessary, there is no point in having them there. if developers submitting patches rebel whenever they do say "no", then there is no point in having them there. that implies the need for an explicitly defined position and probably have an initial public "show of hands" vote of support by the existing contributors to Frameworks to grant the position legitimacy. i honestly don't see having a long term branch working otherwise. and perhaps that's were some of the tension arises: one party is asking for something that doesn't work but which they feel a need for, and the other party doesn't want to do something that doesn't work ;) > - For complex changes the can't safely be applied to the stable branch, a ALL complex changes are in the set of "can't safely be applied" > new branch off of stable is created and the developer issues a call for > testing (maybe on this list). If testing succeeds, it gets merged back to > stable. my recommendation: no. don't even try this. such changes get folded into the next feature version. users will survive. (btw, to keep this grounded in reality: when was the last time we had such a patch for kdelibs or kde-runtime?) > - Updates to the stable branch get released monthly at the same time as the > monthly feature release. that's a lot of overhead to cater to a subset of KDE's audience. since the stable branch is supposed to be always stable, is there any reason why distributions that desire that stability couldn't just grab a snapshot whenever their release schedule deems it suitable? yes, different distros would be running different versions of the same branch, but they'd all be stable. (if the branch isn't stable, then there is no point in the first place.) if the update packages are appended with a git hash (e.g. 5.3-deadbeef) then for developers it becomes a simple matter of using git (or a little script that does) to know whether a particular bug fix is in that package or not. (i know that i certainly do not remember the precise bugfix release number of every fix and often have to resort to git with the current mechanisms..) assuming the stable branch owner does a proper job with their commit messages, a simple `git log ` command could produce an easy-to-grep / ctrl-f list. since it is a stable branch, the number of commits ought to be small. it also resets every "stable branch" cycle. this is not something that needs to scale. -- Aaron J. Seigo
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