Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2015-07-13 at 20:28 -0600, Jonathan Corbet wrote:
> On Mon, 13 Jul 2015 21:02:26 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > Yes, it's great if we can catch things in -next. But I don't believe
> > that patches that fix bugs found in Linus's tree should sit in next
> > before going into Linus's tree, because those patches are basically
> > fixing stuff that was already in next and wasn't discovered until it
> > hit Linus's tree. Which is why I say it's a waste of time to put it in
> > next before sending straight to Linus.
> 
> That, of course, assumes that these fixes don't introduce *other* bugs
> that might just be caught in -next...
> 
> In general, though, I think a lot of people see -next as -rc1 without the
> quality control; it's volatile and scary.  So it's not surprising that it
> doesn't get a lot of real-world testing.  And, as long as that's the case,
> there's going to be a lot of bugs that are never caught in -next.

Yes, I'm with this.  Instantly into Linus' tree means we get a lot of
bug introducing fixes which we then have to sort out.  One of the
complaints the stable tree maintainers and the distros are making is
that it's hard to track the set of patches required for a fix that was
first done wrongly.

No harm comes to us from running regression fixes into -next and thus in
the 0day tests because they eventually get into the correct kernel and
the benefit is that bogus fixes may be picked up by the tests.  Why
would we not incubate for a while in -next when there's no down side and
plenty of upside?

The idea that fixes have to go ASAP without our standard review (and
-next and 0day are now part of our review) processes is completely wrong
in my opinion.

I think we can argue about the time length (or just leave it up to the
maintainer) but saying we should bypass the standard process is wrong.

James