Fwd: KDE Frameworks Release Cycle

[Michael Pyne]

On Tue, May 20, 2014 16:38:54 Aaron J. Seigo wrote:
> 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.

And these are backports done by KDE devs, no? Imagine how bad the regressions 
might be if backports are done only by downstream distributions with far less 
experience with the codebase.

> this has also happen less recently, of course. it just simply _happens_.

This is true, stuff happens. But we have to think about it probabilistically. 
I don't think anyone is asking for an ironclad solution, simply a "give us the 
less bad workable option".

Even the packagers' "no new features" policies can be considered as a 'least-
bad' course of action: I don't think anyone would oppose minor new features 
that can be genuinely, 100% guaranteed to cause no additional bugs or 
regressions whatsoever.

But of course, experience has shown that such guarantees are lies. Taken 
statistically over the mass of commits they package, most of the non-rolling 
distros have converged on "bugfix-only" policies as they provide the best 
tradeoff of fixing bugs and regressions given limited testing and QA budgets 
and timelines for all parties concerned.

Even rolling distros still tend to have varying concepts of branch stability 
as they work to integrate upstream releases. E.g. my Gentoo box only marked 
the 4.12 branch as stable the other day, when we were already up to 4.12.5.

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

Well hey, I think we're now all in agreement. :)

> there is, however, a high rate of success for backported patches. the
> overwhelming majority do what they are supposed to. that is also reality.

Yup.

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

Agreed.

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

Honestly I think they've been fairly clear. The issue is that there are big 
flaws in the current KDE4 development model, which the current proposal is 
trying to address. As it stands now, to get a bugfix to the users quickly you 
have to develop a bugfix and commit against 2 (sometimes 3) different 
branches, and to get a new feature to the users takes ~6 months in the average 
case. And there are ongoing developer-time issues trying to do good testing of 
backported patches.

The proposal aims to fix that by acknowledging the reality that developers are 
not going to be able to always maintain 2-3 separate development branches 
(especially with the exploding number of git modules) by moving to a single 
bugfix+feature development track, but doing rapid iterations to ensure that 
the Frameworks continue to work well together.

I think this has all been clear and explained well enough.

But this shift, while being beneficial to the developers, would be very trying 
to downstream packagers who would have to deal with quite some additional 
issues of their own if this were to be implemented as proposed (we've already 
seen how the proposal had to be modified to account for new library 
dependencies, for instance).

> 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 think I proposed this as a compromise as well. Or rather, accept the reality 
of developer (in-)attention not only by integrating on a single main 
development branch, but also by concentrating the "suck" that goes into 
maintaining a stable branch into one discrete action. At best we would get 
something like the KDE 4 dev process ideal: The developer with the most 
experience of the code backports bug fixes which they feel are important 
(possibly automatically with a commit keyword?), which our distros can all 
ingest backports from in order to do needed testing (since we're still 
acknowledging we're **not** able to do more than automatic/CI testing on 
stable). At worst, we end up with the proposal initially proposed (maybe with 
some downstream packagers working in common to backport patches they need for 
their users on our KDE-provided stable branch).

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

This might be much better (though I wouldn't judge the current stable process 
so harshly). It comes down to "are there maintainers available?", of course, 
but it is certainly more doable than the amorphous "the community is 
responsible for stable" that we've noticed doesn't work too well already.

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

Agreed

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

I was wondering this myself, but in any event if we're willing to release 
tarballs which we haven't even manually verified can be built (after all, our 
packagers will let us know... ;), it wouldn't be much additional overhead I 
think (i.e. could be almost fully scriptable), as Scott has suggested in his 
reply.

Regards,
 - Michael Pyne