[Numpy-discussion] Development workflow
Tue Oct 12 04:31:17 CDT 2010
On 10/12/2010 06:22 PM, Matthew Brett wrote:
>> 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:
>> This really sounds like best-practice to me, and it's even empirically
> 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
>> 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).
More information about the NumPy-Discussion