Fwd: KDE Frameworks Release Cycle
Aaron J. Seigo
aseigo at kde.org
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>
More information about the release-team
mailing list