> I really don't like the double work and the large amount of noise coming > from backporting every other PR to NumPy very quickly. For SciPy the policy > is: > - anyone can set the "backport-candidate" label > - the release manager backports, usually a bunch in one go > - only important fixes get backported (involves some judging, but things > like silencing warnings, doc fixes, etc. are not important enough) > > This works well, and I'd hope that we can make the NumPy approach similar.
Just to add to what Ralf is saying: * people sometimes send PRs against maintenance branches instead of master. In scipy we just label these as backport-candidate, and then the RM sorts them out: which ones to forward port and which ones to backport. This works OK on scipy scale (I had just trawled though a half dozen or so). If numpy needs more backport activity, it might make sense to have separate labels for backport-candidate and needs-forward-port. * A while ago Julian was advocating for some git magic of basing PRs on the common merge base for master and maintenance branches, so that a commit can be merged directly without a cherry-pick (I think). This seems to be beyond a common git-fu (beyond mine for sure!). What I did in scipy, I just edited the commit messages after cherry-picking to add a reference of the original PR a commit was cherry-picked from. Cheers, Evgeni _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
