[Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

[Julian Taylor]

On 19.07.2014 14:09, Ralf Gommers wrote:
> 
> 
> 
> On Sat, Jul 19, 2014 at 1:26 PM, Julian Taylor
> <jtaylor.debian at googlemail.com <mailto:jtaylor.debian at googlemail.com>>
> wrote:
> 
>     On 19.07.2014 13:04, Ralf Gommers wrote:
>     >
>     >
>     >
>     > On Sat, Jul 19, 2014 at 12:29 PM, Pauli Virtanen <pav at iki.fi
>     <mailto:pav at iki.fi>
>     > <mailto:pav at iki.fi <mailto:pav at iki.fi>>> wrote:
>     >
>     >     19.07.2014 11:04, Ralf Gommers kirjoitti:
>     >     [clip]
>     >     >   1. bugfix PR sent to master by contributor
>     >     >   2. maintainer decides it's backportable, so after review he
>     >     doesn't merge
>     >     > PR but rebases it and sends a second PR. First one, with review
>     >     content, is
>     >     > closed not merged.
>     >     >   3. merge PR into maintenance branch.
>     >     >   4. send third PR to merge back or forward port the fix to
>     >     master, and
>     >     > merge that.
>     >     > (or some variation with merge bases which is even more involved)
>     >
>     >     The maintainer can just rebase on merge base, and then merge
>     and push it
>     >     via git as usual, without having to deal with Github.
>     >
>     >
>     > I agree, but note that that's not what's happening in the numpy
>     repo at
>     > the moment and that Julian (and maybe Chuck as well?) is explicitly
>     > against any direct pushes. So the 3x more PRs between what the process
>     > used to be and what Julian proposes is not unrealistic.
>     >
> 
>     It is what is happening at the numpy repo.
>     We are never directly pushing unreviewed changes, we always have at
>     least one PR. We only directly push changes that have been approved to
>     be applied two more than one branch.
> 
> 
> OK never mind then. I was pretty sure you said you were against this,
> and I see a lot of PRs for simple backports in 1.8.x and 1.9.x. If you
> now say it's fine (or even preferred) to push directly, my worry about
> multiple PRs isn't relevant anymore.
> 

thats not what I'm saying.
I'm strongly against pushing unreviewed changes. There must *always* be
at least one PR.
Pushing this PR to multiple branches without another PR is fine with me
if it makes sense in the situation (== the merge is trivial enough to
not need *another* review)