On Sun, Jan 26, 2020 at 11:06 PM Lukas Tribus <[email protected]> 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, -- William
