+1 for (4)
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
