[Numpy-discussion] Could we simplify backporting?

[Ralf Gommers]

On Wed, Feb 22, 2017 at 7:52 AM, Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> Hi All,
>
> In gh-8594, a question came up how to mark things that should be
> backported and Chuck commented [1]:
>
> > Our backport policy is still somewhat ad hoc, especially as I the only
> one who has been doing release. What I currently do is set the milestone to
> the earlier version, so I will find the PR when looking for backports, then
> do a backport, label it as such, set the milestone on the backported
> version, and remove the milestone from the original. I'm not completely
> happy with the process, so if you have better ideas I'd like to hear them.
> One option I've considered is a `backported` label in addition to the
> `backport` label, then use the latter for things to be backported.
>

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.

It seems that continuing to set the milestone to a bug-release version
> if required was a good idea; it is little effort to anyone and keeps
> things clear.


+1

For the rest, might it be possible to make things more
> automated? E.g., might it be possible to have some travis magic that
> does a trial merge & test?


Not sure how you would deal with merge conflicts on cherry-picks in an
automatic backport thingy?

Could one somehow merge to multiple
> branches at the same time?
>

Don't think so.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20170222/146c936a/attachment.html>