On Thu, Sep 24, 2020 at 9:16 AM Nathan Cutler <ncutler@xxxxxxxx> 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#cherry-picking-rules > > > > 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 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
