<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 8:00 AM, Evgeni Burovski <span dir="ltr"><<a href="mailto:evgeny.burovskiy@gmail.com" target="_blank">evgeny.burovskiy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I really don't like the double work and the large amount of noise coming<br>
> from backporting every other PR to NumPy very quickly. For SciPy the policy<br>
> is:<br>
>   - anyone can set the "backport-candidate" label<br>
>   - the release manager backports, usually a bunch in one go<br>
>   - only important fixes get backported (involves some judging, but things<br>
> like silencing warnings, doc fixes, etc. are not important enough)<br>
><br>
> This works well, and I'd hope that we can make the NumPy approach similar.<br>
<br>
<br>
</span>Just to add to what Ralf is saying:<br>
<br>
* people sometimes send PRs against maintenance branches instead of<br>
master. In scipy we just label these as backport-candidate, and then<br>
the RM sorts them out: which ones to forward port and which ones to<br>
backport. This works OK on scipy scale (I had just trawled though a<br>
half dozen or so). If numpy needs more backport activity, it might<br>
make sense to have separate labels for backport-candidate and<br>
needs-forward-port.<br>
<br>
* A while ago Julian was advocating for some git magic of basing PRs<br>
on the common merge base for master and maintenance branches, so that<br>
a commit can be merged directly without a cherry-pick (I think). This<br>
seems to be beyond a common git-fu (beyond mine for sure!). What I did<br>
in scipy, I just edited the commit messages after cherry-picking to<br>
add a reference of the original PR a commit was cherry-picked from.<br></blockquote><div><br></div><div>Cherry-picking is easier, especially when there are only a few backports without conflicts. <br><br></div><div>Chuck<br></div></div><br></div></div>