[Ksummit-discuss] [MAINTAINER SUMMIT] Distribution kernel bugzillas considered harmful
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Wed Sep 5 15:03:15 UTC 2018
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
More information about the Ksummit-discuss
mailing list