[Numpy-discussion] Development workflow
Tue Oct 12 04:22:30 CDT 2010
> 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?
More information about the NumPy-Discussion