* Nathan, are there backport tools that make doing the right thing or
wrong thing easier in situations like this, where multiple commits
will claim to Fix the same bug and some of them are wrong?
Hi Greg:
The short answer is no. A longer answer is:
There is a "backport tool" which can be used to semi-automate the
process of opening the backport PR and cross-linking it with the
backport tracker issue. It is src/script/ceph-backport.sh. While I find
it extremely useful and could not imagine backporting without it, I'm
not aware of anyone else who is actively using it.
That said, this tool does not currently check whether there are multiple
commits that claim to fix the same bug. The script is designed to be run
*after* the user has finished cherry-picking - it does not attempt to
automate the cherry-picking part. Still, I can envision a check for that
being added somewhere near the beginning of the script. Something like:
if there are multiple commits in master that claim to fix the same bug,
bring that to the attention of the user and force them to override the
check by passing an "--ignore-multiple-commits" option. (This would be
somewhat non-trivial to implement because the script would need to use
the Redmine API to introspect the master tracker issue number -
currently it only knows about the backport tracker issue.)
This is the first time I have seen a situation like this. Personally, I
would chalk this one up to the "human factor", which is always lurking
and cannot ever be eliminated, but I welcome your initiative to do a
post-mortem and see how we can improve our workflows to minimize the
probability of this happening again.
One final note: it's pleasant to note that luminous (which is supposed
to be more mature and stable) was not affected.
Nathan
