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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion