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

Reply via email to