+1 for (4). This means that the default settings for a hadoop developer is to get eveyrthing via email. This allows anyone to set filter settings on his/her own email reader to prioritise which types of emails one would like to process-in-depth.
-dhruba On Tue, Jun 23, 2009 at 8:39 PM, Amr Awadallah <a...@cloudera.com> wrote: > +1 for (2) [assuming jira here means a separate mailing list that gets the > full jira traffic] > > My main reasoning is: not all issues are relevant to all people, so we > should let folks select which issues they want to stay fully updated on > (that is why JIRA has the watch functionality). For those who want to keep > track of every single jira update going on then they can join the full > traffic list. I think that is a good compromise between both worlds. My 2 > cents. > > -- amr > > > Doug Cutting wrote: > >> Owen O'Malley wrote: >> >>> I think the community is better served by having a mailing list that is >>> dominated by people posting rather than a deluge of jira traffic. >>> >> >> This is a somewhat false dichotomy: Jira messages are postings by people. >> Folks should not make changes in Jira without realizing this. This is one >> reason why I've long advocated that we should remove the ability for folks >> to edit Jira comments or for anyone but admins to remove Jira comments. If >> we disable emails then this becomes even more essential: folks should not be >> able to re-write project history. >> >> Jira actions are project actions, and the Apache convention is that >> project actions should be logged on public mailing lists. We should change >> that policy cautiously and only after consideration. >> >> Choices: >>> 1. create/resolve/close to dev >>> 2. create/resolve/close to dev, others to jira >>> 3. create/comment/resolve/close to dev >>> 4. all to dev >>> >>> The problem with 3 is that you can add comments on most of the actions. >>> So either you capture all events or you only capture part of the comments. >>> >> >> (4) Send create/resolve to -dev and all others to -issues (a new list) >> plus prohibit all comment edits and permit comment deletion only by admins. >> (Closing is not generally interesting, since it's only done to seal an >> issue once its included in a release.) >> >> +1 for (4) >> >> Doug >> >
