On Thu, Jun 13, 2024 at 10:32:27AM +0200, Thorsten Leemhuis wrote:

> I propose we extend the implications of the "no regressions" rule so
> that mainline developers must ensure fixes for recent mainline
> regression make it to the latest stable series.

I do note that there is already a bunch of disquiet about what makes it
into stable...

> """Developers must ensure that fixes for regressions introduced in the
> last development cycle make it to the latest stable series -- typically
> by adding 'Fixes:' and 'CC: <stable…' tags to the patch description's
> footer."""

Personally I stopped bothering with manually Ccing stable because the
stable team already picks up much more than I'm comfortable with,
devoting any effort to thinking about what might go to stable just
doesn't seem like a good use of time.

We also already have problems with people spamming fixes tags onto
things that are not really bugs or where not much effort appears to have
gone into identifying a relevant commit, I think some people have
internal process pressures on having Fixes tags for the sake of it.
Demanding that people who don't really care fill in the blank to appease
some workflow strategist doesn't seem likely to improve the quality of
information provided any.

> But I'm bringing this up anyway, as users afaics expect "fix recently
> introduced problems with new minor releases', as it is a pretty normal
> thing in most other FLOSS projects that have minor releases. A lot of
> kernel developers are already doing what I proposed anyway. It could be
> viewed as fair to our user base, too. And without it the "no
> regressions" rule might be considered hollow.

I think a lot of projects have a much greater expectation that a large
part of their audience will directly use their releases, while obviously
people do directly take and run kernel releases the much more common
path is via some third party that usually does some integration and QA
work.