Message-ID: <fd9f3d65-dc1b-91fe-1ce7-148c73338e81@leemhuis.info>
Date:   Thu, 27 Jul 2017 12:22:34 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: FYI: Regression tracker now uses an identifier to make tracking
 easier

Hi! TLDR: The Linux regression tracker from now on hands out a tag like
"Linux-Regression-ID: lr#bd29ab" for every issues he tracks. Please
include this string in the comment section of patches that are supposed
to fix the issue. Please also mention the string once in other
mailinglist threads or different bug tracking entries if you or someone
else start to discuss the issue there. By including that string you make
it a whole lot easier to track where an issue gets discussed and how far
patches to fix it have made it. Thx for your help.


Now the longer version (also available on http://bit.ly/lnxregtrackid
where it might get updated if needed):

Linux has no central bug tracker and that is unlikely to change. That
creates special challenges for regression tracking, as issues get
reported in various places -- like LKML, bugzilla.kernel.org and various
other mailing lists and bug trackers. Even worse: regressions discussed
in once place (say bugzilla.kernel.org) often later get discussed
somewhere else (say a LKML thread) before patches are proposed (which
might yet again happen in new LKML threads), before one gets applied to
some git tree and starts its journey to Linux master.

Until now there is no easy was to connect the different places where a
particular regressions and fixes for it get mentioned. That makes
regression tracking a lot of manual, error-prone, and often frustrating
work. To make things a little bit easier I'm asking people to include a
tag in every place where the issue gets handled.  It looks like this:

Linux-Regression-ID: lr#bd29ab

The regression tracker will create the ID when he adds a regression to
his list and then will mentioned the ID in the mailing list thread or
the bug entry where that regression was reported. That also makes sure
the people involved get aware the regression is tracked and mentioned in
the weekly reports.

Mentioning the tag once per mailinglist thread or bug entry is enough,
as the regression tracker then start to monitor that place. If that
works well I might be able to automate regression tracking a bit and let
software do more of the boring work. For now the regression tracker will
simply search for that string when compiling his reports.

That's all for now -- there imho is no need to talk about things like
"how to point out dupes", as for now there is still a human that
interprets the text when the string "Linux-Regression-ID:" shows up
somewhere.

I'll see how that goes and when might start to write some scripts to
automate handling. Or does anyone know a software that we could use for
this? Or one that might be a good starting point for something
customized (patchwork might be)? Suggestions welcome.

BTW, you might wonder why the regression tracker doesn't simply use the
commit-ID from  the change that lead to the regression. Problem is: In
quite a lot of cases the commit that caused a regression is not yet know
when the regressions starts to get trackend.

Anyway: Thanks for your help. And a small reminder: If you as a
developer or tester want to make sure a regression gets tracked in my
reports simply let regression@...mhuis.info know -- for example by CCing
it to a mail, by forwarding a mail to that address or by sending a small
mail with a quick pointer to some discussion or bugtracking entry. Many thx!

Ciao, Thorsten

Powered by blists - more mailing lists