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

[Greg KH <greg@kroah.com>]

On Tue, Sep 01, 2015 at 11:44:40AM +0300, Jani Nikula wrote:
> On Tue, 14 Jul 2015, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 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.
> 
> Digging up an old thread, sorry...
> 
> I think one of the issues with the stable process is that when we add
> stable tags (or Fixes: references) they are cast in stone in the commit
> history. We can fix the code and everyone sees the current version, but
> when you look at a commit intended for stable, it's not always as
> trivial to figure out whether that was a good idea in hindsight.
> 
> When I sort out the drm/i915 fixes for current development kernels (or
> -next) I often spend quite a bit of time doing git log/blame archeology
> figuring out if it's a regression fix and what the regressing commit
> was, etc. I've thought about scripting the git history to add git notes
> to the commits that are referred to by later commits, as this would be
> helpful in figuring out if there are *other* commits fixing issues in
> the same regressing one. Alas I've never found the time.
> 
> I'm wondering if people would think it worthwhile to have a
> collaborative effort of annotating commits using git notes, both
> automatically and manually. The manual annotations might be things like,
> "Cc: stable", "whoops, this was a bad idea for stable", or "this also
> needs commit foo in stable". Of course, with more structure, but you get
> the idea.

git notes are a pain to propagate around, so while I like the idea of
this, I don't know how well the proposed solution would work.

thanks,

greg k-h