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 Re: more information about project split
Date Wed, 24 Jun 2009 16:52:44 GMT
+1 for (4)

On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur <dhruba@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 <aaa@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
>>>
>>
>


Mime
View raw message