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

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

On Wed, Sep 05, 2018 at 12:37:15PM +0100, Mark Brown wrote:
> On Wed, Sep 05, 2018 at 11:13:52AM +0100, James Bottomley wrote:
> 
> > The first suggestion is that kernel builds are pretty much automated
> > and we try to make every commit buildable, so could we automate the
> > machinery that allows a customer to do bisection simply by installing a
> > kernel package? (we here, obviously means the distro, but going from
> > git bisect to kernel package would be the useful link).
> 
> Improving bisectability would obviously help with other testing efforts
> too - we have existing users, Guillaume Tucker implemented automated
> bisection support in KernelCI which is incredibly useful providing one
> can actually bisect.  Right now it works pretty well a lot of the time
> but there are cases where it gets messy, especially when you add boot
> issues onto the buildability ones.

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,
but that sounds difficult, painful, and error-prone.  Could added tooling
make bisection work better?  Sounds valuable, but non-trivial.

In some of my bisection efforts, I have had to apply fix patches to
fix various unrelated bugs.  I suppose that this could be automated,
for example by tracking which fix-patches are needed at which potential
bisection points, though this sounds like a large effort.  Of course,
automated backporting of patches would make it easier, and much else
easier as well.  ;-)

							Thanx, Paul