Doug, given Owen's away this week, can you update the Jira config to
implement (4). Until this is done, the patch testing process can't
see when Jira's change states and thus nothing is getting tested.
Thanks,
Nige
Begin forwarded message:
From: Hemanth Yamijala <yhema...@yahoo-inc.com>
Date: June 24, 2009 9:55:47 PM PDT
To: <core-dev@hadoop.apache.org>
Subject: Re: more information about project split
Reply-To: core-dev@hadoop.apache.org
+1 for (4).
Jim Kellerman (POWERSET) wrote:
+1 for (4)
-----Original Message-----
From: Doug Cutting [mailto:cutt...@gmail.com] On Behalf Of Doug
Cutting
Sent: Tuesday, June 23, 2009 11:32 AM
To: core-dev@hadoop.apache.org
Subject: Re: more information about project split
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
