[Numpy-discussion] Development workflow

[David]

On 10/12/2010 06:22 PM, Matthew Brett wrote:
> 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?

I think it is a little too extreme for trivial changes like one-liner 
and the likes, but I think it is a good default rule (that is if you are 
not sure, don't push your own changes).

cheers,

David