Mailing List Options [was Re: Switching...]

[Chris Shoemaker]

On Sun, Oct 30, 2005 at 02:15:37PM -0500, Josh Sled wrote:
> On Sun, 2005-10-30 at 20:01 +0100, Didier Vidal wrote:
> > I've always wondered why the commits are systematically sent to
> > gnucash-patches... This results in noise and an additional chance to
> > forget or loose patches (since no dedicated tool exists to manage them).
> > 
> > Why not just sending the patches, the patches acknowledgments and the
> > patches commits to gnucash-patches ?
> 
> I guess there's an argument for minimizing mailing-list management...
> but I could certainly see having 3 lists:
> 
> - gnucash-patches (manual patch submission + ack + discuss)
> - gnucash-changes (commit notification, w/ diffs)
> - gnucash-commits (commit notification, w/o diffs)
> 
> Or, optionally, only the first 2.

My reflection on our development process has influenced my thinking
about mailing lists, too.  FWIW, here's my 50 cents:

There should be only 2 lists: -users and -devel.

Reasoning:
  X  -patches should go to -devel.  
     * All submitted patches should be up for discussion.
     * It's hard to know before hand what patches actually will generate 
        discussion.
     * It's hard to move the thread after-the-fact.
     * Anyone willing to subscribe to -devel *should* be willing to see 
        the trafic that -patches would get.
  X  -changes should go to -devel.
     * Any commited change might generate discussion.
     * Again, hard to know before; hard to move after.
     * Again, anyone on -devel should be willing to see commits.
  X  -commits should go to /dev/null.
     * There are better ways to syndicate the commit log than a mailing 
        list.
     * But, if there *has* to be a place for emails of the commit log,
        it shouldn't be the same list where the full diffs go.

In conclusion, -devel is for *development* and development involves
patches so I think any setup that keeps source code off -devel is not
good.

-chris