On Tue, May 22, 2012 at 10:26:02AM +0200, Urs Liska wrote: > Dear Susan, > > I think this makes sense (although I can't tell if it really is what > Colin wanted to express ...).
It was pretty close. Thanks, Susan, you write well. > Do I understand correctly that what you describe is one possible > strategy to take care of the integrity of the main source tree? Yes. Integrity in the sense that it passes (I'm guessing) these three tests: no errors from Lilypond, the scores look good, and the midi sounds fine. > And another one would be what I have the impression is going on with > LilyPond development: Every contributor can commit updates, but they > are only merged to the main or master tree after some kind of review > process? Yes. > What I'm feeling slightly uneasy about with your suggestion is that > it relies on some kind of 'lock' state. Nobody except the owner of > the build token is allowed to update the master branch. Yes, that's right. They are responsible for moving the head of the master branch forward. > This is only acceptable if it is somehow enforced by the system and > doesn't rely on the reliability of the people involved. You have to be able to rely on your team. > And I feel this may lock up things if someone doesn't give back the > token fast enough? Yes. Susan's point about "small commits and often" is very important, and more so as your project approaches a release date. Traditionally, in a shared office, people use a rubber chicken or a ball. You throw it to each other. In distributed teams subject-only emails work well e.g. From: Urs Subj: I'm taking the build token (Urs integrates new spacer rest layout) From: Urs Subj: Build token free. (Rest of team do a git fetch or something like that) From: Susan Subj: Taking the build token (Susan integrates new coda section) etc etc Cheers, Colin. -- Colin Hall _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
