commit emails

[Matthew Fluet]

> I would definitely vote for human-generated mail as opposed to automatically
> generated, but I guess it is up to you.  I know that with the stuff at NEC
> the E-mail was basically spam.  It was too frequent to make it worth trying
> to pick out what was important, so the people just ended up using manual
> E-mail when something was worth commenting on.

I agree with Stephen that there is a bit of redundancy.  I usually compose
an e-mail, cut and paste it into the logs, and then send it to MLton.  But
Henry is right that there could be quite a bit of spam.  For example, all
those Makefile changes in the last couple of days.

We might decide on an e-mail policy.  You can associate an arbitrary
program with the commit, so some shell scripting and grep could get some 
simple (or even complex) policies.  Here are a couple of ideas that came
to me:
1. forward the commit log for any commit that changes doc/CHANGES; those
   tend to be the big important changes.
2. forward the commit log for any commit log that contains the string
   "Send to list" or something simpler

There are probably some others.  For me, it tends to be a case by case
basis looking at the output of cvs -q update; if it's something I wasn't
expecting to change, I'll take a look at it.  But, if I know the important
items are going out on email, I'll probably just take it on faith that the
remainder are minor changes.