Dhruba, I can't set email filters for which jiras I am interested in getting full updates on, that would mean I have to set an additional filter for each jira ticket one by one, not very scalable. Is that what you suggesting?
On 6/23/09, 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 >>> >> >
