On Thu, Sep 24, 2020 at 9:16 AM Nathan Cutler <ncutler@suse.com> wrote:
Today it came to my attention that not all Ceph developers agree with the following cherry-picking rule:
"if a commit could not be cherry-picked from master, the commit message must explain why that was not possible" [1]
[1] https://github.com/ceph/ceph/blob/master/SubmittingPatches-backports.rst#che...
From what I've seen myself, we strictly enforce this rule. I agree with the rationale you've shared above. Any PR against a stable branch that includes (OR excludes!) commits or fixes not present on master must explain why.
Thanks for your quick response, Patrick! Would you agree, then, to change the rule to allow the explanation of "why" to be done outside of the commit messages themselves?
Yes, I think having the discussion in the PR is also suitable. Otherwise where in the commit history would you document a missing commit form a series in a backport.
My concern is that by intentionally not including the explanation in the commit message, we are effectively withholding the explanation from future users of the git history. To put it another way, folks who are unfortunate enough to be involved in the kind of forensic examination I described will not benefit from explanations that are offered up in a PR or tracker issue.
GitHub/tracker discussions are all official metadata associated with the git history. It's not feasible to make git (commits) the SSOT. (Maybe when git adds changesets/reviews/issues we can get to that point. :) -- Patrick Donnelly, Ph.D. He / Him / His Principal Software Engineer Red Hat Sunnyvale, CA GPG: 19F28A586F808C2402351B93C3301A3E258DD79D