Re: [PATCH v1 5/6] docs: 6.Followthrough.rst: more specific advice on fixing regressions

[Jonathan Corbet <corbet@lwn.net>]

Thorsten Leemhuis <linux@leemhuis.info> writes:

> Provide something more concrete about fixing regressions in a few
> places, as telling people to "expedite" fixing those that reached a
> release deemed for end users is pretty vague. But every situation is
> different, so use the soft phrases like "aim for" and leave loopholes.
>
> This removes equivalent paragraphs from a section in
> Documentation/process/handling-regressions.rst, which will become mostly
> obsolete through this and follow-up changes.
>
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
>  
> - - If the culprit was mainlined during the current development cycle and not
> -   backported to stable, fix the regression before -rc6.
> + - Expedite fixing regressions that recently reached releases deemed for end
> +   users through new mainline releases or stable backports.  If the culprit

Again, I wouldn't used "deemed" this way.

> +   reached it in the past six weeks, aim to mainline a fix before the end of the
> +   week after the next; if it landed during the past year, taking one more week

Can we say "within ten days" or some such instead?

> +   is fine.  Whenever possible, try to resolve the issue faster -- but it's also
> +   okay to take more time if there are strong reasons and a revert no option.
>  
> - - If a proper regression fix is unlikely to become ready in a reasonable
> -   timeframe, resolve the regression by reverting the culprit.  This is
> + - If the culprit was mainlined during the current development cycle and not
> +   backported to stable, fix the regression before -rc6. But try to resolve it
> +   faster whenever possible -- especially if the issue is either reported
> +   multiple times or prevents CI systems or multiple users from testing, as that
> +   might mask other bugs and drive testers away.
> +
> + - Try your best to mainline all regressions fixes before the current

"regression" singular

> +   development cycle ends, unless the culprit was committed more than a year
> +   ago: then it is acceptable to queue a fix for the next merge window, which
> +   is even advisable in case the change bears bigger risks.

Thanks,

jon