On 13.12.24 17:28, Jonathan Corbet wrote: >> + - Expedite fixing regressions that recently reached releases deemed for end >> + users through new mainline releases or stable backports. If the culprit >> + 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? Well, I chose that approach due to various small reasons that add up: - Many of us know that -rc releases are not special, but a lot of people seem to focus on them. For all of them it's not much of a differences if a fix is mainlined on Monday (Pacific Time) or Friday of the same week. - Greg often prepares new stable releases early during a week, so for any fix that needs to land there it's ideal if it reaches a new -rc, as then Greg will often pick it automatically soon afterwards; anything merged on Monday or Tuesday will likely miss a new stable-rc and thus often take a week longer to reach users, unless it's one of those weeks where Greg does more than one release per week. - I highly doubt that many subsystem maintainers will care much about such a "10 days for individual regressions" target, as that might easily mean they have to send additional PRs just to reach that goal. IOW: it will likely be ignored or even laughed at. And I don't blame them. That's why I went with something that developers and subsystem maintainers can actually implement, especially for the bigger subsystems where the weekdays when PRs to Linus are usually send are known. Side note & reminder: overall the biggest problem I see wrt to fixing regressions is that fixes exists, just take a quite a while to make it through the ranks (review, merge to subsystem tree, PR to linux). Especially the last step. Which is why patch 6 has that "Furthermore try to avoid holding onto regression fixes over weekends -- especially when some are marked for backporting to stable series." in it. Ciao, Thorsten
