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
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,
> 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
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
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