Hi,<br><br>One non-zero-sum approach would be to leverage an email aware service such as <a href="http://www.posterous.com">Posterous</a>. By investing a few minutes of time the board could obtain an email address at <a href="http://posterous.com">posterous.com</a> to send commits to. Then people could use any RSS reader they wanted and use or create more powerful Squeak-based tools for search/repurposing. With a few more minutes Posterous can be configured to autopost to Twitter, Tumblr or many other places. I&#39;ve already done this(<a href="http://squeakcommits.posterous.com/">http://squeakcommits.posterous.com/</a>) for my own benefit and also so folks can see but<a href="http://smalltalkworld.posterous.com/announcement-squeak-commits"> it would be better IMO for it to be an official feed</a>. <br>
<br>It&#39;s worth considering me thinks, that according to the <a href="http://wiki.squeak.org/squeak/608">Squeak Wiki </a><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
The primary mailing list for anyone interested in programming in
Squeak. It is a lively and busy forum for discussion on all things
related to Squeak!
<br></blockquote><br>so getting a screen full of commit messages is probably not a good first experience for the seasoned developer coming from another language looking for how to *use* Squeak rather than maintain/develop it. Maybe there needs to be another list for folk not working on the trunk but regardless of which way things go choices are available.<br>
<br>Laurence<br><br><div class="gmail_quote">On Tue, Oct 20, 2009 at 11:35 PM, Andreas Raab <span dir="ltr">&lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Folks -<br>
<br>
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):<br>

<br>
        &quot;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&#39;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.&quot;<br>

<br>
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&#39;t be filtered easily), the spam factor is considerable.<br>

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

<br>
I&#39;m curious what people think about this idea or if you have other proposals for balancing these tradeoffs. We&#39;ll need some help with the mailman setup as well since at the very least we&#39;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&#39;d do it we&#39;ll have to make sure that the initial report is within reason and need some help here.<br>

<br>
Cheers,<br><font color="#888888">
  - Andreas<br>
<br>
</font></blockquote></div><br>