On Fri, Feb 24, 2017 at 8:00 AM, Evgeni Burovski wrote: 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. Cherry-picking is easier, especially when there are only a few backports
without conflicts.
Chuck