[Numpy-discussion] Could we simplify backporting?

[Charles R Harris]

On Fri, Feb 24, 2017 at 8:00 AM, Evgeni Burovski <evgeny.burovskiy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20170224/2d43754a/attachment.html>