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,


Reply via email to