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
