[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Fwd: KDE Frameworks Release Cycle
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2014-05-20 20:38:26
Message-ID: 398c44e2-7e30-4946-9e72-9a3ccf82de23 () email ! android ! com
[Download RAW message or body]

On May 20, 2014 10:38:54 AM EDT, "Aaron J. Seigo" <aseigo@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


_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]