Re: [Ksummit-discuss] [CORE TOPIC] Regression tracking

[Takashi Iwai <tiwai@suse.de>]

On Tue, 09 Aug 2016 21:02:22 +0200,
Thorsten Leemhuis wrote:
> 
> On 09.08.2016 11:40, Joerg Roedel wrote:
> > On Wed, Jul 27, 2016 at 02:28:26PM +0200, Thorsten Leemhuis wrote:
> >> On 26.07.2016 22:36, Rafael J. Wysocki wrote:
> > 
> >>>> There were other people trying to do that when I had stopped doing it, but
> >>>> they gave up eventually.
> >> Yeah, I guess that can easily happen sooner or later, because from what
> >> I can see it's a lot of manual and boring work that only now and then
> >> feels rewarding :-/
> > […] But I think
> > this will also involve teaching our testers/users on how to best report
> > regressions.
> 
> Yeah, definitely. One afaics important part that needs to be done in
> this area: make bugzilla.kernel.org work better. At least some (or maybe
> even quite a lot?) of the bugs reported there afaics seem to not get
> proper attention from the right people. Due to that I'd assume some
> testers will have come to conclusions like "testing for regressions and
> bugs is not worth the trouble, as the kernel developers are not
> interested in the bugs I file anyway".

Right, unfortunately Bugzilla is often left uncared although we've
already got a regression report.

Meanwhile there is a regression flag already in bugzilla.kernel.org,
and this could be automatically sending a notification to you.  Then
you can ping the corresponding maintainer.

> > Part of the discussion should also be on automation, for
> > example if we could/should revive the kerneloops tool?
> 
> Ugh, what's the latest status of it? I just saw
> http://www.kerneloops.org/ is kind of alive again as
> http://oops.kernel.org/ (I had missed that) and has data from recent
> kernel versions. But it seems the code behind it hasn't seen much
> changes in the last two years:
> https://github.com/oops-kernel-org/kerneloops/commits/master
> 
> Side note: kernelopps and error reporting was talked about on KS2013:
> https://lwn.net/Articles/571997/ ABRT was mentioned there. Fedora these
> days by default installs abrt-addon-kerneloops (see
> https://abrt.readthedocs.io/en/latest/supported_langs.html#linux-kernel
> for a very brief intro). Things it picks up can be seen on
> https://retrace.fedoraproject.org/faf/summary/ The Fedora kernel package
> maintainers use the data afaik, but I don't know any more details.
> Anyway: ABRT is quite Fedora/RH specific and quite heavy. IOW: it is not
> something other distros can easily integrate like it happened with the
> original kerneloops tool years ago.

Yeah, I'm afraid that it's too heavy-weight.  And overall, I guess
you'd get way too many noises by that, more than the really useful
data.

IMO, the possible tactics is to educate subsystem maintainers to
properly report regressions.  Ideally, you wouldn't have to handle any
bugs by yourself, but just let your slaves debugging, and report back
to you the status :)


Takashi