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'...
