On Fri, Feb 24, 2017 at 8:00 AM, Evgeni Burovski <evgeny.burovs...@gmail.com > 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
