Hi Greg et al,
On Wed, Jul 14, 2021 at 7:36 PM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Jul 14, 2021 at 01:21:59PM -0400, Theodore Y. Ts'o wrote:
> > On Wed, Jul 14, 2021 at 05:46:22PM +0200, Greg Kroah-Hartman wrote:
> > > The number of valid cases where someone puts a "Fixes:" tag, and that
> > > patch should NOT be backported is really really slim. Why would you put
> > > that tag and not want to have known-broken kernels fixed?
> > >
> > > If it really is not an issue, just do not put the "Fixes:" tag?
> >
> > I think it really boils down to what the tags are supposed to mean and
> > what do they imply.
> >
> > The argument from the other side is if the Stable maintainers are
> > interpreting the Fixes: tag as an implicit "CC: stable", why should we
> > have the "Cc: stable" tag at all in that case?
>
> I would love to not have to look at the Fixes: tag, but today we have to
> because not all subsystems DO use cc: stable.
>
> We miss loads of real fixes if we only go by cc: stable right now. If
> you can go and fix those subsystems to actually remember to do this
> "properly", wonderful, we will not have to mess with only Fixes: tags
> again.
>
> But until that happens, we have to live with what we have. And all we
> have are "hints" like Fixes: to go off of.
IMHO the biggest issues with "Cc: stable" are that (a) in general
it's hard to know if a patch is (not) worthwhile to be backported,
and (b) without a Fixes: tag it doesn't tell you what version(s)
it should be applied to.
Just having a Fixes: tag fixes the latter, and allows you to defer
the decision to backport.
> > We could also have the policy that in the case where you have a fix
> > for a bug, but it's super subtle, and shouldn't be automatically
> > backported, that the this should be explained in the commit, e.g.,
> >
> > This commit fixes a bug in "1adeadbeef33: lorem ipsum dolor sit
> > amet" but it is touching code which subtle and quick to anger, the
> > bug isn't all that serious. So please don't backport it
> > automatically; someone should manually do the backport and run the
> > fooblat test before sumitting it to the stable maintainers.
>
> That's wonderful, I would love to see that more, and we do see that on
> some commits. And we mostly catch them (I miss them at times, but
> that's my fault, not the developer/maintainers fault.)
In my experience, the hardest cases are the ones where a patch fixes
a real bug, but the fix has an obscure implicit dependency on another
commit in a different subsystem (e.g. driver and DTS interaction).
When backporting, a regression is introduced if the dependency
is not present yet in the stable tree.
> > Andrew seems to be of the opinion that these sorts of cases are very
> > common. I don't have enough data to have a strong opinion either way.
> > But if you are right that it is a rare case, then sure, simply
> > omitting the Fixes: tag and using text in the commit description would
> > work. We just need to agree that this is the convention that we all
> > shoulf be using.
> >
> > I still wonder though what's the point of having the "Cc: stable" tag
> > if it's implicitly assumed to be there if there is a Fixes: tagle.
>
> Because cc: stable came first, and for some reason people think that it
> is all that is necessary to get patches committed to the stable tree,
> despite it never being documented or that way. I have to correct
> someone about this about 2x a month on the stable@vger list.
For a developer, it's much easier to not care about "Cc: stable"
at all, because as soon as you add a "Cc: stable" to a patch, or CC
stable, someone will compain ;-) Much easier to just add a Fixes: tag,
and know it will be backported to trees that have the "buggy" commit.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
