On Fri, Apr 15, 2011 at 07:11:21PM -0400, m...@apollinemike.com wrote: > > I agree - it is for this reason that I feel the only two solutions are to: > > (1) Freeze pushes to the master branch save ones that are > explicitly authorized by Graham.
Oh god no. > (2) Keep working at our normal pace, but split off stable > versions to which only bug fixes will be applied. (3) any "big" change -- say, any patch that takes longer than 6 hours to write -- is done on a separate branch, and only merged with master once we have good reason to believe that it's finished. Git is designed to handle tons of branches. Painless branching and merging is pretty much the biggest feature point of git! In our recent history, I'd say that the MIDI rewrite and beam avoidance code rewrite are ideal candidates for being worked on separate branches. NB: I'm not talking about a single "development" branch. I'm talking about having a dozen separate branches, one for each feature. You and Han-Wen could have work on the dev/beaming branch. Jan and anybody interested could have worked on the dev/midi branch. You and Reinhold could have worked on the dev/footnotes branch. Etc. Yes, there will probably still be unexpected problems when we finally merge one of those "feature" branches with master... but by isolating the "new feature" development work from master, we'll have a more stable central branch, and we can test a specific new features after merging in a much more focused way. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel