hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Daley <nda...@yahoo-inc.com>
Subject Fwd: more information about project split
Date Thu, 25 Jun 2009 06:42:38 GMT
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 <yhemanth@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:cutting@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
>>>
>>
>>
>


Mime
View raw message