[squeak-dev] Commit messages revisited

Andreas Raab andreas.raab at gmx.de
Wed Oct 21 03:35:25 UTC 2009


Hi Folks -

We had a little board discussion about the commit messages posted to 
Squeak-dev and I wanted to move the discussion over here. I think there 
are some excellent arguments to be made for commit messages in general, 
both from the point of awareness, but perhaps more importantly because 
(quoting from a message that said it better than I could):

	"The real value comes when, for example, someone like Dan Ingalls who 
is reading squeak-dev but not tracking active development notices a 
change in code which he has an interest in or knowledge of and catches 
an issue that might otherwise go unnoticed for a significant period of 
time.  Better yet, when someone not otherwise engaged sees a submission 
that really grabs her imagination and inspires her to contribute or 
develop some piece of software using the ideas.  Related these bits of 
code have educational value.  I don't believe any digest view is going 
to have the same value for the simple reason that most people are not 
going to look past the subject of the message or maybe the first few 
lines, that is the one and only chance to grab them."

I think this is a great summary for why these messages are useful. On 
the other hand, when something happens like in the last two days where 
we have literally some fifty commit messages clogging the inbox, the 
viewers at gmane or nabble (which can't be filtered easily), the spam 
factor is considerable.

What I have been proposing is to use the mailman digest features to have 
the commit messages go to a separate commit list and cross-post a daily 
digest from the commit list to Squeak-dev. This should help us to keep 
awareness up and I think dealing with a single commit summary per day 
would keep the volume low enough for people to keep up with.

I'm curious what people think about this idea or if you have other 
proposals for balancing these tradeoffs. We'll need some help with the 
mailman setup as well since at the very least we'll need to limit the 
amount for the diffs to something reasonable or else these message will 
go over the limit for Squeak-dev. We have also discussed a more 
elaborate approach that creates repository hierarchies to search for 
ancestor versions but whichever way we'd do it we'll have to make sure 
that the initial report is within reason and need some help here.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list