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.
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. 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? Could one somehow merge to multiple branches at the same time? I have no idea myself really how these things work, but maybe some of you do! All the best, Marten
On Wed, Feb 22, 2017 at 7:52 AM, Marten van Kerkwijk < m.h.vankerkwijk@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. 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
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
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
On Wed, Feb 22, 2017 at 7:52 AM, Marten van Kerkwijk < m.h.vankerkwijk@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. 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
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
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
participants (5)
-
Charles R Harris -
Evgeni Burovski -
Julian Taylor -
Marten van Kerkwijk -
Ralf Gommers