Hello,
On Sun, 26 Jan 2020 at 20:11, William Dauchy <w.dau...@criteo.com> wrote: > > > The explanation of the user-visible impact and the need for > > backporting to stable branches or not are MANDATORY. > > Yes; I was simply challenging that, as it is also open to mistakes to > write in commit message to which version it should be backported. My two cents: 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. Here are some examples as to why we would not backport a specific fix: - the change may not be needed (no user impact) - the change may be to complex or unfeasible for the specific branch - there is a good chance that the change will have branch specific side-effects (for example in a subsystem that is significantly different or fragile in that branch) - the issue may be so minor that it doesn't make sense for the specific branch (think for example Critical fixes only branches) 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). Otherwise committers need to repeat the research the author already did, to figure out whether or not a backport is needed. Your patch here is a simple one-line change, and everything is probably immediately obvious (I did not read the code change myself), but that's not very common, often a lot of complexity is involved (even with one-line code changes) and committers or stable branch maintainers must not be spending their time researching issues while backporting (otherwise nothing will get backported). If you think commit 456 should be backported to all the branches that have 123, please research what branches have 123 and spell that out in the commit message, referring to that branch, like we usually do: [Must|Should] be backported to 1.8. Backports are always cherry-picked. Commits that are not cherry-picked have been committed to the particular branch when it was master (or a patch has been specifically written for a particular stable branch, but that's very rare). > it is also open to mistakes to write in commit message > to which version it should be backported. Of course it is open to mistakes, everything is. We try to minimize it, but we don't claim or expect perfection from anybody. Like I said, those are my two cents, Lukas
