+1 for (4). I agree with Doug that JIRAs are often used for discussion. I wouldn't mind getting the Hudson reports excluded (wow, what a surprise! -1 for failed tests in contrib), but otherwise, I enjoy how having JIRA send emails pushes many folks to consolidate discussions on the JIRA instead of in email.
On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur <dhr...@gmail.com> wrote: > +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 > >> > > >
