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

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Sep 05, 2018 at 05:45:14PM +0100, James Bottomley wrote:
> 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.

So I am not the only one doing this.  ;-)

> > 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.

I use date-coded branches to keep the old commits around.  I delete
them periodically, but keep them around for at least six months, on the
theory that if you are developing against a two-year old -rcu branch,
you have bigger problems.  And you should have instead developed against
a formal release anyway.

							Thanx, Paul