Fwd: KDE Frameworks Release Cycle

Tue May 20 14:38:54 UTC 2014

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
-------------- 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/20140520/cd20c377/attachment.sig>