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

2017-02-24 Thread Charles R Harris
On Fri, Feb 24, 2017 at 8:00 AM, 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

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

2017-02-24 Thread Julian Taylor
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,

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

2017-02-24 Thread Evgeni Burovski
> 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

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

2017-02-22 Thread Marten van Kerkwijk
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

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

2017-02-22 Thread Ralf Gommers
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