Kernel regression tracking, part 1 [LWN.net]

Kernel regression tracking, part 1

Posted Nov 1, 2017 7:01 UTC (Wed) by corbet (editor, #1)
In reply to: Kernel regression tracking, part 1 by neilbrown
Parent article: Kernel regression tracking, part 1

I do believe the point is to (1) have a sense for how ready a given kernel is, and (2) increase the odds that regressions get fixed rather than falling through the cracks.

to post comments

Kernel regression tracking, part 1

Posted Nov 1, 2017 16:14 UTC (Wed) by knurd (subscriber, #113424) [Link] (1 responses)

I'd add (3) (or many (2b)): get maintainers back on track in case they do not take regressions seriously (like it was the case recently with AppArmor: https://lkml.org/lkml/2017/10/3/1)

Kernel regression tracking, part 1

Posted Nov 1, 2017 22:14 UTC (Wed) by neilbrown (subscriber, #359) [Link]

> like it was the case recently with AppArmor: https://lkml.org/lkml/2017/10/3/1

This is not an example of "maintaining a regression list is useful". This is an example of "members of the community supporting each other to encourage change". James reported a regression, the maintainer disagreed, someone else (Thorsten, and eventually Linus) joined in to make the case.
You don't need a maintained list of regressions to get things fixed (and I doubt it helps much). You need people to care and report and contribute and persist.

We always need more competent people to follow issues in various fora, to review not only patches but also bug reports and design discussions and anything else. In this case Thorsten Leemhuis joined in and pushed things along. This was a valuable contribution to be applauded, but it is not a contribution that needs to be centralized; it just needs to be done. Were you following the thread at the time? Maybe even you could have pushed things along.

Kernel regression tracking, part 1

Posted Nov 1, 2017 21:29 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

> (1) have a sense for how ready a given kernel is

Given that mainline is the only focus discussed, and given the current development model, this seems to mean "should Linus release an -rc7, go straight to -final". If that is ever a hard decision, the just default to -rc7. In fact, I wonder why we don't have a fixed N-week cycle (with variation on if Linus' holidays require it).

> (2) increase the odds that regressions get fixed rather than falling through the cracks

Does it though? And is it the most beneficial way to achieve that?

My core point is that regression tracking is best done in a distributed fashion (like everything else in the community except "being Linus" which is centralized). If you find a regression then it is your responsibility to push for a solution, just as if I find a regression it is mine. If we both hit the same regression then we might end up working together and pushing harder for less individual effort.
The more people who take responsibility, the more data, testing, and expertise is available, and the more likely it is that a fix will be found. I think that reporting a bug and following through to a solution is a good way for people of any skill level to feel connected with the community. Giving people responsibility is an important first step to them taking it. If a "regression maintainer" takes that responsibility, we say to the community "we don't need you".

Kernel regression tracking, part 1

Posted Nov 1, 2017 22:59 UTC (Wed) by Paf (subscriber, #91811) [Link]

Maybe instead we say “check with this person” and “I know you don’t have time or don’t know how to follow up, so here’s someone who’s committed to making that easy”.

Not “we don’t need you”, but “we know you have little time, so here’s help”.