Re: Possible amendment to the cherry-picking rules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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?

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.

Nathan
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux