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

[Laura Abbott <labbott@redhat.com>]

On 09/05/2018 06:39 AM, Konstantin Ryabitsev wrote:
> On Wed, Sep 05, 2018 at 03:16:59PM +0200, Takashi Iwai wrote:
>>> Second suggestion is that the bugzillas need to say much more strongly
>>> that the reporter really needs to confirm the fix in upstream and do
>>> the bisection themselves (and ideally request the backport to stable
>>> themselves).
>>
>> OK, distros definitely need to try hard not to annoy upstream devs.
>>
>> In the case of SUSE Kernel, we usually ask testing the latest
>> (more-or-less) vanilla kernel at first.  If it's an upstream problem,
>> then it's often tossed to the upstream.  If it's already addressed in
>> the upstream kernel, we take the responsibility for backports.  Asking
>> bisection by reporter is usually the last resort.
>>
>> It'd be helpful if we get any suggestion to improve the process.
> 
> It would be awesome to have a "bisect@home" type of thing with a similar
> idea like seti@home and folding@home. Have a central queue where
> developers can submit upstream commits and testcases, and a swarm of
> volunteer drones would grab and bisect-build them until the
> bug-introducing commit is identified and reported back.
> 
> I'll totally host the hell out of this.
> 

I played around with bisect scripts for Fedora a while ago but mostly
abandoned them due to lack of interest and fragility. I was attempting
to use the full Fedora patch set and spec file but making that work
for arbitrary kernel commits was a pain.

Developers usually have no problem building and bisecting kernels,
it's non-kernel developers who often struggle with bisection.
One idea that I haven't followed up on was to extend the existing
targets for building distro packages to just build the source
side of things and then take advantage of existing environments
(e.g. COPR) to build the package binaries. I'd love a web interface
that would handle some of this automatically but, again, lack of
resources and knowledge of web frameworks.

Thanks,
Laura