Thanks, Warren, You are right that gerrit is probably overkill for a project with relatively few contributors, and people who seem to generally work well together with a lot of dramatic flare-ups and such...
Interesting about lilypond... Gerrit seems to be associated with Jenkins, that automatically builds everything whenever anyone makes a change. So the testing is automated. Again, nice for a big project, probably less essential for a small one. I'm going back into lurking mode now... meg >________________________________ > From: Werner LEMBERG <w...@gnu.org> >To: dreidellh...@yahoo.com >Cc: groff@gnu.org >Sent: Monday, March 10, 2014 11:01 PM >Subject: Re: [Groff] commit policy > > > >Hello Meg! > > >> The flaw I see to Werner's proposed policy is that comments and >> discussions are not stored in the git repository for posterity. We >> are using gerrit, which is a lovely review tool, in conjunction with >> git and it's a rather lovely system. > >I've worked with gerrit, and I don't like it very much. It makes >sense if there is a very large contributor base, and if the code base >is similarly large. For a relatively small project like groff with >such a small number of contributors, I consider it overkill. > >In case there are essential discussions regarding a patch, the right >policy IMHO is to add a link to the mailing list, pointing to the >discussion. The same holds for bug reports. > > > > Werner > > >PS: With GNU lilypond, we use a different approach. > > . patches are uploaded to google's `rietveld' system > > . our `patch meister' runs the patch and checks whether it breaks > the system, or if the regression tests show any issues > > . after a countdown allowing for comments, a patch gets committed > to a `staging' branch > > . if the automatic build system works fine, the pending patches > in `staging' are finally applied to `master' > > While working and useful, this needs a person acting as the `patch > meister'... > > > >
