How to use espeakup, revisited...

[Tony Baechler]

Hi,

I have a further suggestion which might solve the below problem with 
people not being informed of changes.  I know that Debian and all the 
BSD branches do something similar.  That is to create a separate list 
where new change logs would automatically be posted.  There was a list 
called speakup-cvs for that purpose but it's dead now.  The reason for 
making it a separate list is to avoid potentially cluttering this list 
with excess traffic in which most people aren't interested.  For major 
releases, an announcement can still be posted here as has been done 
recently (thanks Chris and William) but for small changes, the output of 
git-log could be posted to a new speakup-git list.  I think such a new 
list would have moderate traffic.  Sometimes several days go by with no 
activity but other times there are several small changes in a day.  I'm 
fairly sure that git has a facility to do this.  The Linux kernel also 
has a list which posts changes and it is kept in git.  I think I saw 
something called git-mail but I could be imagining things.  Is this a 
good idea?  I'm not skilled enough with git to do it myself, but perhaps 
Kirk could create the list and someone could set this up.  Any thoughts?

On 9/22/2009 3:23 PM, Gregory Nowak wrote:
> While I'll agree that it would be nice to see a list of changes posted
> here as they happen, I don't think this is strictly necessary, that's
> what the very well detailed changelog is for. Once you've checked
> speakup out from git, switch to the directory with the sources, and
> do:
> git log
> and you'll want to pipe that through your favorite pager of
> course. If you get speakup as a package from your distribution's
> repository, then there should be a changelog included with your
> package. To summarize, while it would be nice to see a list of changes
> posted here periodically, if it comes down to the development team
> spending time on duplicating already existing information, or instead
> spending that time on fixing bugs/implementing new features, I'd
> rather see the developers use that time to do the latter personally.
>