### Re: [Numpy-discussion] Could we simplify backporting?

On Fri, Feb 24, 2017 at 8:00 AM, Evgeni Burovskiwrote: > > 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

### Re: [Numpy-discussion] Could we simplify backporting?

On 24.02.2017 16:00, Evgeni Burovski 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. > from the bugfix branch: git rebase --onto $(git merge-base master maintenance) HEAD^ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

### Re: [Numpy-discussion] Could we simplify backporting?

> 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

### Re: [Numpy-discussion] Could we simplify backporting?

Hi Ralf, Yes, good to think about other policies. For astropy, we do the decision by labelling with the bug-fix branch (with a policy that it really should fix a bug), and inserting text in that release's bug-fix notes (we really should automate that part...). Then, backporting is done shortly before the bug-fix release and, as far as I can tell (not having done it myself), outside of github. In rare cases with hard-to-resolve merge conflicts, the original PR author gets a note asking for help. As for a travis test: here I was mostly thinking of an allowed-to-fail test that would at least alert one if backporting was going to be an issue. I think travis runs again once one merges, correct? If so, on that merge it could, in principle, do the backport too (if given enough permission, of course; I'm not sure at all I'd want that, just pointing out the possibility! E.g., it might trigger on a message in the merge commit.). All the best, Marten ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

### Re: [Numpy-discussion] Could we simplify backporting?

On Wed, Feb 22, 2017 at 7:52 AM, Marten van Kerkwijk < m.h.vankerkw...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion