[Numpy-discussion] Development workflow

[Matthew Brett]

Hi,

> I think there are two issues here:
>
> (A) How to be sensible and presentable
>
> (B) How and when your stuff gets into master

A very useful distinction - thanks for making it.

> For (A) I'm following the same workflow I had with the git mirror:
>
> 1. For *every* change, create a separate topic branch.
>
> 2. Work on it until the feature/bugfix is ready.
>
> 3. Push it to my own github clone for review/backup purposes if necessary.
>
> 4. If necessary, rebase (not merge!) on master when developing
>   to keep in stride.
>
> 5. When ready, (i) rebase on master, (ii) check that the result is
>   sensible, and (iii) push from the topic branch as new master.
>
> In this case, since all recent changes are just unrelated stand-alone
> bugfixes, this produces something that looks very much like SVN log :)
>
> I think of the above, 1-4 are okay in all cases. 5 is then perhaps not so
> absolute, as one could also do a merge if there are several commits. I
> 100% endorse Fernando's recommendations:
>
>    http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html
>
> This really sounds like best-practice to me, and it's even empirically
> tested!

OK - so it seems to me that you agree with Fernando's recommendations,
and that's basically the same as what Stefan was proposing (give or
take a rebase), and David agreed with Stefan.   So - really - everyone
agrees on the following - work on topic branches - don't merge from
trunk - rebase on trunk if necessary.  I think _insisting_ on rebase
on trunk before merge with trunk is a little extreme (see follow-up to
ipython thread) - but it's not a big deal.

> Then there's the second question (B) on when core devs should push
> changes. When ready, when reviewed, or only before release?
>
> I would be open even for the "radical" never-push-your-own-changes
> solution.
>
> I think we could even try it this way for the 1.5.1 release. If it seems
> that unhandled pull requests start to accumulate (which I don't think
> will happen), we could just reverse the policy.

OK - right - that's the second big issue and obviously that's at the
heart of thing.  I think that splits into two in fact:

i) How often to merge into trunk
ii) Who should merge into trunk

At the extreme, you have the SVN model where the answers are:

i) a merge for almost every commit
ii) by the person who wrote the code

and I thought that we'd decided that we didn't want that because trunk
started getting unpredictable and painful to maintain.

At the other end is the more standard DVCS-type workflow:

i) merges by branches (which might have only a few commits)
ii) by small team of people who are responsible for overseeing trunk.
And rarely by the person who wrote the code

So - is that a reasonable summary?

Does anyone disagree with Pauli's never-push-your-own-changes suggestion?

Best,

Matthew