Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]

On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
> Before the "3.10.1-stable review" thread degenerated into a disagreement
> about habits of politeness, there were some solid points being made
> which, I think, bear consideration and which may now be lost.
> 
> The problem, as Jiří Kosina put is succinctly is that the distributions
> are finding stable less useful because it contains to much stuff they'd
> classify as not stable material.

Well, some distributions may find that.  Some distribution maintainers
have taken on stable branches, officially or otherwise - Steven Rostedt
(MRG), several Ubuntu developers, and myself (Debian), and of course
Greg was working for SUSE not so long ago.

Myself, I suspect I've been too eager to backport fixes to 3.2 and that
this has led to some avoidable regressions.  I hope I'm striking
approximately the right balance now.

> The question that arises from this is who is stable aiming at ...
> because if it's the distributions (and that's what people seem to be
> using it for) then we need to take this feedback seriously.
> 
> The next question is how should we, the maintainers, be policing commits
> to stable.  As I think has been demonstrated in the discussion the
> "stable rules" are more sort of guidelines (apologies for the pirates
> reference).  In many ways, this is as it should be, because people
> should have enough taste to know what constitutes a stable fix.  The
> real root cause of the problem is that the cc: stable tag can't be
> stripped once it's in the tree, so maintainers only get to police things
> they put in the tree.  Stuff they pull from others is already tagged and
> that tag can't be changed.

Sure it can.  Subsystem maintainers can reject a pull request and demand
changes that include rebasing.  (But only reasonably for leaf
repositories.)

> This effectively pushes the problem out to
> the lowest (and possibly more inexperienced) leaves of the Maintainer
> tree.  In theory we have a review stage for stable, but the review
> patches don't automatically get routed to the right mailing list

This is a simple matter of programming.

> and the
> first round usually comes out in the merge window when Maintainers'
> attention is elsewhere.

That is a real problem.  It's also a time when those changes have not
had much testing together.  (Yes there is linux-next, but I seriously
doubt it gets as much run-time testing as mainline.)

> The solution, to me, looks simple:  Let's co-opt a process we already
> know how to do: mailing list review and tree handling.  So the proposal
> is simple:
> 
>      1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
>         reviewed patch to stable
>      2. All patches to stable should follow current review rules: They
>         should go to the mailing list the original patch was sent to
>         once the original is upstream as a request for stable.
>      3. Following debate on the list, the original maintainer would be
>         responsible for collecting the patches (including the upstream
>         commit) adjudicating on them and passing them on to stable after
>         list review (either by git tree pull or email to stable@).
>
> I contend this raises the bar for adding patches to stable much higher,
> which seems to be needed,

I think it would be an over-correction...

> and adds a review stage which involves all the original reviewers.

...but this is important.  Also, I'm not convinced that the current
standard review period (48 hours starting whenever) is really long
enough.  Especially when there can be 4 large series at once (for 3.0,
3.4, 3.latest-1 and 3.latest) or even more if other stable maintainers
start overlapping reviews.

Ben.

> Oh, and did someone mention plum brandy ...?

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]