Thorsten Leemhuis <li...@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 <li...@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
