Messages in this thread | | | From | Thorsten Leemhuis <> | Subject | FYI: Regression tracker now uses an identifier to make tracking easier | Date | Thu, 27 Jul 2017 12:22:34 +0200 |
| |
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@leemhuis.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
| |