hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amr Awadallah <...@cloudera.com>
Subject Re: more information about project split
Date Wed, 24 Jun 2009 16:32:38 GMT

  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

On 6/23/09, 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

View raw message