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:
signature.asc
Description: This is a digitally signed message part