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

[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 "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?

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

[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 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?

[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 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?

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

[Numpy-discussion] Could we simplify backporting?

[Marten van Kerkwijk]

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