On Sun, Jan 26, 2020 at 11:06 PM Lukas Tribus <lu...@ltri.eu> wrote:
> Just because commit 456 fixes something that has been introduced with
> commit 123 DOES NOT mean we backport 456 to all the branches that 123
> was committed to - instead we backport 456 to a certain branch if it
> *actually* makes sense to do so.
> This is not something a VCS will figure out for us, but is a human
> decision. The author should be suggesting it's intention regarding the
> backport in the commit message, because it's the one person that spend
> the most time with the issue and probably has the best understanding
> of its impacts as well as the complexity and necessity of a backport.
> That does not mean the author needs to tests the fix with those
> branches, send branch-specific diff's, or do other research regarding
> the backport, but *the intention needs to be stated* (based on the
> research already conducted for the matter at hand). If the committer
> (or reviewer) disagrees, it will be clarified. If during the backport
> issues come up, those issues will be dealt with then (this happens
> latter, not when the fix is committed to master).

yes, that's why I was more talking about a semi automatic process,
which only suggests to do a backport with this tag.
I am thinking about examples like on netdev linux kernel subsystem, a
"Fixes:" tag suggests that it is a possible candidate for stable
branches, but then it's up to the maintainer to decide whether to
backport it or not.

Anyway, that being said, I have nothing against adding those messages,
it was a suggestion.

Thanks for the discussion,

Reply via email to