Fwd: KDE Frameworks Release Cycle

[Scott Kitterman]

On May 20, 2014 10:38:54 AM EDT, "Aaron J. Seigo" <aseigo at kde.org> wrote:
>hi ...
>
>it would be interesting to see a true cost/benefit analysis using real
>data of 
>the benefits of the monthly bug fix releases. 

It would. I've no idea how to do it.  My impression is providing them is popular with our users. At one point it was popular with KDE developers too.

>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.

Agreed. 

>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...

For Kubuntu, we're in the no regressions camp.  After one of our releases we consider we have a "contract" with our users not to break stuff that's working. 

>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.

It doesn't do app devs any good to use releases that their users aren't going to have.

>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?

For non-rolling distros, 6 months seems like a pretty standard interval.  I picked the end of Q1/Q3 just because an end of December release would hit a non-productive time of year for a lot of people.

>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.

I have this hope months of stable will be an easier sell the TBD until KF5 is out. 

>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. ;)

It's possible there's some irony my word choices. I have zero objections to lots of interim releases if that works for KF5, but having something stable is essential. 

>>  - 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 ;)

This is a great idea. 

>>  - 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?)

I added this due to a suggestion from (I think Martin) in the last thread that this would be helpful. I think it's something we could experiment with. 

>>  - 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.

It's a good point. Programmatically it's easier for me if there's a point that upstream has blessed, but I think with your stable release management proposal it's possible to manage this without it being high overhead. Maybe "release" is a script that is run monthly that adds a tag for a common snapshot across all of KF5, but no travails?

Scott K