[Numpy-discussion] Could we simplify backporting?

[Evgeni Burovski]

> 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