Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Distribution kernel bugzillas considered harmful

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

On Wed, 2018-09-05 at 09:20 -0700, Paul E. McKenney wrote:
> On Wed, Sep 05, 2018 at 11:50:08AM -0400, Steven Rostedt wrote:
> > On Wed, 5 Sep 2018 08:03:15 -0700
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > 
> > > I am one of those strange people who rebase in order to improve
> > > bisectability.  But one reason I can do that is that I have
> > > relatively
> > > few patches, and it gets harder the more patches I am
> > > carrying.  I suppose
> > > that someone (not me!) could rebase -stable to make it more
> > > bisectable,
> > 
> > How would rebasing it make stable more bisectable? Once you rebase,
> > you don't have a tree that use to work? Although I guess you may
> > find the commit that caused the problem better. But rebasing
> > creates a lot of other issues, I would not recommend rebasing
> > stable, as that would totally break the RT stable tree work flow.
> 
> Instead of leaving the buggy commit and the span where the bug
> exists, you rebase the fix into the original buggy fix.

We do this in SCSI as well, but only if the tree hasn't yet been
submitted to Linus.  The technical term is folding.  It's obviously
better to fix buggy commits that haven't gone upstream because it
improves bisectability.

> And I bet that rebasing -stable would cause no end of broken glass in
> a great many  projects.  ;-)

If others rely on your tree, rebasing is harder and must be done more
carefully and with co-ordination, but it's not impossible assuming you
have a problem big enough.  Again, it's an expediency based trade off.

James