> > I was thinking later that there is another point of failure in the
> > backport process that is demonstrated in this incident -
> > An elephant in the room even -
> > We have no *standard* way to mark a patch as a bug fix,
> > so everyone is using their own scripts and regex magic.
> >
> > Fixes: is a standard that works, but it does not apply in many
> > cases, for example:
> >
> > 1. Zero day (some mark those as Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2"))
> > 2. Hard work to figure out the fix commit
> > 3. Discourage AUTOSEL
>
> For security fixes, just marking a bug as fixing a security bug, even
> if you try to obfuscate the Fixes tag, is often enough to tip off a
> potential attacker. So I would consider:
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2"))
>
> to Not Be A Solution for security related patches. The real fix here
I miswrote. I meant fixes for bugs that existed since day 1.
The annotation above is adequate, but is also a bit ugly IMO.
>
>
> The hard work to figure out the fix commit is a real one, and this is
> an example of where the interests of upstream and people who want to
> do backports come into partial conflict. The more we do code cleanup,
> refactoring, etc., to reduce technical debt --- something which is of
> great interest to upstream developers --- the harder it is to
> idetntify the fixes tag, and the harder it is to backport to bug and
> security fixes after the tech debt reduction commit has gone in. So
> someone who only cares about backports into product kernels, to the
> exclusion of all else, would want to discourage tech debt reudction
> commits. Except they know that won't fly, and they would be flamed to
> a crisp if they try. :-)
>
> I suppose one workaround is if an upstream developer is too tired or
> too harried to figure out the correct value of a fixes tag, one cheesy
> way around it would be to use:
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2"))
>
I am sure that we can be more expressive than that :)
I suggested:
Fixes: ????
Not as a joke. It is more descriptive than the above which could really
mean "I know this bug existed since day 1"
> to basically mean, this fixes a bug, but I'm not sure where it is, and
> it's long enough ago that maybe it's better if we ask the backport
> folks to figure out the dependency if the patch doesn't apply cleanly
> as to whether or not they need to do the code archeology to figure out
> if it applies to an ancient kernel like 4.19 or 5.10, because again,
> the product backport folks are likely to outnumber the upstream
> developers, and the product backport folks are linked to revenue
> streams.
>
> So I would argue that maybe a more sustainable approach is to find a
> way for the product backport folks to work together to take load off
> of the upstream developers. I'm sure there will be times when there
> are some easy things that upstream folks can do to make things better,
> but trying to move all or most of the burden onto the upstream
> developers is as much of an unfunded mandate as Syzbot is. :-/
>
The funny thing is that my rant was about a cover letter written
by an upstream developer, so unless what you mean is that backport
teams should invest in review and make those comments during
review, then it's too late by the time the backport team got to do their job.
You raise the resources problem and I understand that, but
I am not looking for a solution that creates more work for upstream
maintainers. Quite the contrary.
I am simply looking for a standard way to express
"attention backport teams".
What I am looking for is a solution for this problem:
Developer/maintainer has information that can be very helpful to backport
teams.
The information is known at the time of the writing and it requires no extra
effort on their part, but is not mentioned in a standard way because there
is no standard way that does not incur extra work.
Some maintainers that I am working with are very diligent about requiring Fixes:
when applicable.
It may be because of $$$ as you say, but I have a more romantic interpretation.
I believe it is because they care about the code they are developing and they
understand that mainstream is not a product and has no real user.
Unless maintainers care about downstream products, real users will perceive
their code as bad quality - no matter whose responsibility it was to
backport the
fixes or point out to the relevant fixes.
Thanks,
Amir.
