On 06/12/12 13:23, Sean Leather wrote:
On Thu, Dec 6, 2012 at 1:29 PM, Simon Peyton-Jones wrote:
My own understanding is this:
A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way.
The current mailing lists:
* glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting * cvs-ghc: for GHC *developers*
I don't think we want to confuse users with developers. If we flood users with dev-related conversations they'll get fed up.
I don't see a very useful distinction between glasgow-haskell-users and glasgow-haskell-bugs. The distinction was very important before we had a bug tracker, but it doesn't seem useful now.
I can see a perhaps-useful distinction between two *developer* lists (A) human email about implementation aspects of GHC (B) machine-generated email from buildbots etc
I rather think that (A) could usefully include Trac ticket creation and Git commit messages, since both are really human-generated.
I think the last two things (tickets and commit messages) should be separate from a mailing that is intended for (email-only) discussion. The content may be human-generated, but:
(1) The number of messages is overwhelming. Alternatively stated, if you consider each ticket or commit message a different thread (which many email clients do), the number of different threads is large. (2) The commit messages do not all lead to conversations, and most of the discussion on tickets takes place on Trac with every message duplicated to the list.
Consequently, any email-only discussion threads on the mailing list can easily get lost among all the other threads.
So that would leave only buildbot logs on (B).
So I would be content to * Abolish glasgow-haskell-bugs in favour of glasgow-haskell-users * Split out cvs-ghc into two in some way; details to be agreed.
But for me the issue is not a pressing one.
I identify the following different needs:
(1) User email discussion (2) Developer email discussion (3) Buildbot reports (4) Trac reports (5) Commit messages
Sounds good to me. I like the idea of separating out the buildbot reports too, because there tends to be little signal in those (I typically only look at one per day, just to check whether there's anything really broken). Although that problem could be solved a different way, by having the build server emit a single email with a good summary once per day. Cheers, Simon