We now have 3 subprojects common, hdfs, and mapreduce that replace the  
old core. Their urls are:

Common:
core-{user,dev,commits}@hadoop.apache.org  - these will be replaced by  
common-*
https://svn.apache.org/repos/asf/hadoop/common/
https://issues.apache.org/jira/browse/HADOOP

HDFS:
hdfs-{user,dev,commits}@hadoop.apache.org
https://svn.apache.org/repos/asf/hadoop/hdfs/
https://issues.apache.org/jira/browse/HDFS

Map/Reduce:
mapreduce-{user,dev,commits}@hadoop.apache.org
https://svn.apache.org/repos/asf/hadoop/mapreduce/
https://issues.apache.org/jira/browse/MAPREDUCE

For the new Jiras, I currently have them set to only send out email to  
the dev list on create, resolve, and close. All events still go to the  
creator, assignee, and watchers.

-- Owen

Owen O'Malley wrote:
> We now have 3 subprojects common, hdfs, and mapreduce that replace the
> old core. Their urls are:

[...]

> For the new Jiras, I currently have them set to only send out email to
> the dev list on create, resolve, and close. All events still go to the
> creator, assignee, and watchers.

I would like to receive the updates (at least the ones with comments)
without having to watch each of them. not that I read each of them. One
alternative could be to have *-jira mailing lists for jira updates?

Of all the people, I would expect hadoop engineers to be least bothered
about "more data" :)

Raghu.

Raghu Angadi wrote:
> I would like to receive the updates (at least the ones with comments)
> without having to watch each of them.

+1 The full process should be logged in email.

Doug

I like Owen's approach better, we will get an email every time a ticket
is created or resolved, and we can selectively watch the one's you want
to see immediate updates on. That strikes the proper balance between
being informed of what is going on without being flooded. It also had
the added benefit of measuring the interest for a certain jira based on
how many watchers it has.

A possible compromise would be to create a list like hdfs-dev-watcher@
which gets emails for all jira events, and folks how want to be watching
everything can subscribe to that.

-- amr

Doug Cutting wrote:
> Raghu Angadi wrote:
>> I would like to receive the updates (at least the ones with comments)
>> without having to watch each of them.
>
> +1 The full process should be logged in email.
>
> Doug

I really prefer the current approach, but clearly we need to reach  
consensus. Last week we had a case where a developer sent to the users  
lists because he thought that dev was reserved for jira traffic. That  
is a bad sign. Doug is the most prolific non-jira poster to core-dev  
and in 37th place. 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.

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.

-- Owen

Any option except (1). Having a separate mailing list for jira traffic
is probably the best option (ie. option 2).

Even with just create/resolve sent to dev, the Jira traffic would still
dominate.

Raghu.

Owen O'Malley wrote:
> I really prefer the current approach, but clearly we need to reach
> consensus. Last week we had a case where a developer sent to the users
> lists because he thought that dev was reserved for jira traffic. That is
> a bad sign. Doug is the most prolific non-jira poster to core-dev and in
> 37th place. 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.
>
> 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.
>
> -- Owen

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

+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

+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 <[EMAIL PROTECTED]> 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
>>
>

+1 for (4). I agree with Doug that JIRAs are often used for discussion. I
wouldn't mind getting the Hudson reports excluded (wow, what a surprise! -1
for failed tests in contrib), but otherwise, I enjoy how having JIRA send
emails pushes many folks to consolidate discussions on the JIRA instead of
in email.

On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >>
> >
>

+1 for (4)

On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur <[EMAIL PROTECTED]>  
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 <[EMAIL PROTECTED]>  
> 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
>>>
>>
>

> 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.

I think all events with human comments should go to dev. Events without
comments, or comments by machines (hudson) only go to watchers. if you
can't do this in Jira yet, time to raise a support call with Atlassian.

different apache projects have different processes, its interesting to
see how they work.
* Ant: watch the SVN commit, commit-then-forgive development, email
based discussion, some bugzilla for external bugs
   -very agile, everyone watches the commit log, Works if the rate of
change is low. Weak at tracking the history of decisions back to
individual changes.

* Axis: more planning on bugzilla, more discussion before commit. And,
when IBM were the main engineering staff, prone to having big changes
made without much in the way of online discussion. The co-located team
achieved agility by bypassing bits of the community

* Maven2: almost pure JIRA. a distributed team working out their IDe.
Very hard to get involved in the team, as there is less sense of
community, more of people working on problems. And Jira is so very, very
noisy, especially if you use IDE-integration tools like mylyn, that turn
every issue into a page as noisy as a facebook entry.

* Hadoop.
    -very big development team, globally distributed. Although Y!
provide a lot of that team, its a lot more open than in Axis, for which
I have to credit Owen, Doug and others: community outreach is hard, but
they have put in the effort.
   -comments let you know what issues are live, being worked on. Even if
you skip them, they give you a feel for what is going on, which helps
you get an idea of what's changed when something stops working.

I think its really hard to track what's going on in Hadoop, the only
thing that makes it possible is the fact that the tests take hours to
run, and here in the UK we are at a lull in the development cycle
between asia and the US. I get a chance to catch up on things, and a
stable codebase,.

Now if you will excuse me, I have to find out why the shuffling stops
working when I bind a single-machine cluster to 127.0.0.1 instead of the
external address...

-steve

Another option, which I've used extensively, is to make use of the rss
feeds JIRA provides for all filters, issues lists and
contributors/commitor actions.  I have separate rss feeds for added
recently, resolved recently and blockers.  This allows me to track these
events without crowding my email client and then watching the ones of
interest.  Pretty much everything on the main project page has an rss
version of it.  doesn't go down to the commit level, but rss feeds
provide a very customizable view.  If even more trickery is required,
Yahoo! Pipes should be able to create whatever you need.

-Jakob
Steve Loughran wrote:
>
>  > 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.
>
> I think all events with human comments should go to dev. Events without
> comments, or comments by machines (hudson) only go to watchers. if you
> can't do this in Jira yet, time to raise a support call with Atlassian.
>
> different apache projects have different processes, its interesting to
> see how they work.
>
>
> * Ant: watch the SVN commit, commit-then-forgive development, email
> based discussion, some bugzilla for external bugs
>   -very agile, everyone watches the commit log, Works if the rate of
> change is low. Weak at tracking the history of decisions back to
> individual changes.
>
> * Axis: more planning on bugzilla, more discussion before commit. And,
> when IBM were the main engineering staff, prone to having big changes
> made without much in the way of online discussion. The co-located team
> achieved agility by bypassing bits of the community
>
> * Maven2: almost pure JIRA. a distributed team working out their IDe.
> Very hard to get involved in the team, as there is less sense of
> community, more of people working on problems. And Jira is so very, very
> noisy, especially if you use IDE-integration tools like mylyn, that turn
> every issue into a page as noisy as a facebook entry.
>
> * Hadoop.
>    -very big development team, globally distributed. Although Y! provide
> a lot of that team, its a lot more open than in Axis, for which I have
> to credit Owen, Doug and others: community outreach is hard, but they
> have put in the effort.
>   -comments let you know what issues are live, being worked on. Even if
> you skip them, they give you a feel for what is going on, which helps
> you get an idea of what's changed when something stops working.
>
> I think its really hard to track what's going on in Hadoop, the only
> thing that makes it possible is the fact that the tests take hours to
> run, and here in the UK we are at a lull in the development cycle
> between asia and the US. I get a chance to catch up on things, and a
> stable codebase,.
>
> Now if you will excuse me, I have to find out why the shuffling stops
> working when I bind a single-machine cluster to 127.0.0.1 instead of the
> external address...
>
> -steve
>

Steve and co,

  I would really appreciate if you guys can propose a solution that
works for me, I am sorry if I am coming across as a pain in the behind,
but please help :)

  To re-iterate, not all JIRAs are imporant to me, there are some key
ones that I would like to get all updates on, and there are others that
I would just like to check once in a while but don't really have
capacity to be getting email updates for. How do we accommodate that?

  For example, should I just unsubscribe from core-dev@ and follow the
the individual jiras? Can we create a separate mail list (e.g.
core-dev-create@) so I get an alert email when new issues are created
and then selectively watch/follow?

  Here is an example of recently filed JIRA that I don't really need to
get all updates on:

https://issues.apache.org/jira/browse/HADOOP-6098

  And here is an example of one that I would like to get all updates on:

https://issues.apache.org/jira/browse/HDFS-265

  I really don't want to complicate things for the heavy weight
developers who want to be monitoring every single update going on for
every single JIRA, but at the same time I would really appreciate if you
guys can figure out a solution that works for somebody like me.

Thanks,

-- amr

Steve Loughran wrote:
> > 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.
>
> I think all events with human comments should go to dev. Events
> without comments, or comments by machines (hudson) only go to
> watchers. if you can't do this in Jira yet, time to raise a support
> call with Atlassian.
>
> different apache projects have different processes, its interesting to
> see how they work.
>
>
> * Ant: watch the SVN commit, commit-then-forgive development, email
> based discussion, some bugzilla for external bugs
>   -very agile, everyone watches the commit log, Works if the rate of
> change is low. Weak at tracking the history of decisions back to
> individual changes.
>
> * Axis: more planning on bugzilla, more discussion before commit. And,
> when IBM were the main engineering staff, prone to having big changes
> made without much in the way of online discussion. The co-located team
> achieved agility by bypassing bits of the community
>
> * Maven2: almost pure JIRA. a distributed team working out their IDe.
> Very hard to get involved in the team, as there is less sense of
> community, more of people working on problems. And Jira is so very,
> very noisy, especially if you use IDE-integration tools like mylyn,
> that turn every issue into a page as noisy as a facebook entry.
>
> * Hadoop.
>    -very big development team, globally distributed. Although Y!
> provide a lot of that team, its a lot more open than in Axis, for
> which I have to credit Owen, Doug and others: community outreach is
> hard, but they have put in the effort.
>   -comments let you know what issues are live, being worked on. Even
> if you skip them, they give you a feel for what is going on, which
> helps you get an idea of what's changed when something stops working.
>
> I think its really hard to track what's going on in Hadoop, the only
> thing that makes it possible is the fact that the tests take hours to
> run, and here in the UK we are at a lull in the development cycle
> between asia and the US. I get a chance to catch up on things, and a
> stable codebase,.
>
> Now if you will excuse me, I have to find out why the shuffling stops
> working when I bind a single-machine cluster to 127.0.0.1 instead of
> the external address...
>
> -steve

Amr Awadallah wrote:
> To re-iterate, not all JIRAs are imporant to me, there are some key
> ones that I would like to get all updates on, and there are others that
> I would just like to check once in a while but don't really have
> capacity to be getting email updates for. How do we accommodate that?

I think the currently favored proposal (4) can meet your needs.  Under
this, Jira will only send messages to the -dev list when issues are
created or resolved.  All other Jira messages will go to just the
-issues list.  (Commits are already routed only to the -commits list.)

You would subscribe to the -dev list but not the -issues list.  On
seeing a create message, you can elect in Jira to watch an issue to
receive all updates to that issue.  Folks who want to see all issue
updates might subscribe to the -issues and -commits lists as well.

Does this meet your needs?

Doug

> Does this meet your needs?

Doug,

  The way you describe it below works great for me, I must have
misunderstood what (4) means, from Owen's email it said:

 > 4. all to dev

as opposed to create/resolve to dev, and all to issues (which I am
totally ok with and would work great for me).

Thanks,

-- amr

Doug Cutting wrote:
> Amr Awadallah wrote:
>> To re-iterate, not all JIRAs are imporant to me, there are some key
>> ones that I would like to get all updates on, and there are others
>> that I would just like to check once in a while but don't really have
>> capacity to be getting email updates for. How do we accommodate that?
>
> I think the currently favored proposal (4) can meet your needs.  Under
> this, Jira will only send messages to the -dev list when issues are
> created or resolved.  All other Jira messages will go to just the
> -issues list.  (Commits are already routed only to the -commits list.)
>
> You would subscribe to the -dev list but not the -issues list.  On
> seeing a create message, you can elect in Jira to watch an issue to
> receive all updates to that issue.  Folks who want to see all issue
> updates might subscribe to the -issues and -commits lists as well.
>
> Does this meet your needs?
>
> Doug

Amr Awadallah wrote:
> The way you describe it below works great for me, I must have
> misunderstood what (4) means, from Owen's email it said:
>
>> 4. all to dev
>
> as opposed to create/resolve to dev, and all to issues (which I am
> totally ok with and would work great for me).

Oops, I added a new option that I called (4), but should have called (5):

> (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.)

Lots of folks +1'd (4) after this, and I thought they were voting for my
(4), not Owen's.

If anyone meant to vote for Owen's, not mine, please speak up.

Sorry for the confusion!

Doug

On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:

>
> Oops, I added a new option that I called (4), but should have called (5):
>
>  (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.)
>>
>
> Lots of folks +1'd (4) after this, and I thought they were voting for my
> (4), not Owen's.
>
> If anyone meant to vote for Owen's, not mine, please speak up.
>
> Sorry for the confusion!
>
Ahhh....

I *didn't* vote for (4) because I missed the overload.

+1 for 4'

+1 for 4' :)

-- amr

Ted Dunning wrote:
> On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:
>
>  
>> Oops, I added a new option that I called (4), but should have called (5):
>>
>>  (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.)
>>>
>>>      
>> Lots of folks +1'd (4) after this, and I thought they were voting for my
>> (4), not Owen's.
>>
>> If anyone meant to vote for Owen's, not mine, please speak up.
>>
>> Sorry for the confusion!
>>
>>    
>
>
> Ahhh....
>
> I *didn't* vote for (4) because I missed the overload.
>
> +1 for 4'
>
>  

Of course the 4' is much closer to my choice #2, which makes me happy too. +1

My apologies for bringing this thread back to the top of your mailbox
(especially after my gmail vacation filter spammed y'all), but while
we're here, a follow-on question on e-mail habits:

I personally rewrite (using a series of hacks) my JIRA e-mail in two ways:

1) I change the subject to remove the JIRA "action", so, for example:
   [jira] Commented: (HADOOP-5649) Enable ServicePlugins for the JobTracker
becomes
   (HADOOP-5649) Enable ServicePlugins for the JobTracker'

2) I change the "from" line to something unique per user, so:
   "George Porter (JIRA)" <[EMAIL PROTECTED]>
becomes
   "George Porter (JIRA)" <[EMAIL PROTECTED]>
The from address is broken, but I've added a reply-to to
[EMAIL PROTECTED], so the current behavior of replies going as comments
to the JIRA still happens.

This makes GMail behave much better.  GMail threads by subject line
(instead of any headers), and this allows for messages about a single
JIRA to thread together, unless the JIRA subject changes, which is
pretty rare.  And JIRA colors the posts by user, and, in the index
view, indicates what users are participating, and rewriting the from
line helps me out there too.  For example, I'll ignore a thread where
the only new message is from the Hudson bot and where I'm not
personally involved.

Would other people find this useful?  Would everyone find this useful,
or do people get a lot of information in the
"Created/Updated/Resolved/Commented/Edited/..." designation in the
subject-line?  If people found it useful, it would be pretty easy to
put a rewriting script in the pipeline for the mailing list.  If only
some people found it useful, I'd be happy to set up shadow lists or
some other contrivance.

Cheers,

-- Philip

P.S.: Code for my scripts is at
http://github.com/philz/jira-rewrite/tree/master .

Keep your subscription, but add a filter to divert or delete all JIRA
notices that come from the mailing list.  Then, subscribe individually to
JIRAs.  Since their notices won't come from the mailing list, you will still
get these.

On Fri, Jun 26, 2009 at 10:03 AM, Amr Awadallah <[EMAIL PROTECTED]> wrote:

>  For example, should I just unsubscribe from core-dev@ and follow the the
> individual jiras? Can we create a separate mail list (e.g. core-dev-create@)
> so I get an alert email when new issues are created and then selectively
> watch/follow?
>
>  Here is an example of recently filed JIRA that I don't really need to get
> all updates on:
>
> https://issues.apache.org/jira/browse/HADOOP-6098
>

Ted Dunning wrote:
> Keep your subscription, but add a filter to divert or delete all JIRA
> notices that come from the mailing list.  Then, subscribe individually to
> JIRAs.  Since their notices won't come from the mailing list, you will still
> get these.

Yes, the common practice is to shunt all messages sent to the list but
"create" and "resolve" messages to a folder, mark them unread, or
somesuch, and in Jira, to watch issues whose "create" message piques
one's interest.  The point of splitting non-create or -resolve messages
to a -issues list is to make this configuration simpler for new
developers, so that they do not have to configure filters but rather can
simply subscribe to only the -dev list.

Doug

Dhruba,

  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
suggesting?
On 6/23/09, Dhruba Borthakur <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>
>>
>

What I use to filter mails for jiras I am more interested in
(watching/created/assigned...) :

  from : [EMAIL PROTECTED]
  to : [EMAIL PROTECTED]

hope it helps.
Raghu.

Amr Awadallah wrote:
> Dhruba,
>
>   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
> suggesting?
>
>
> On 6/23/09, Dhruba Borthakur <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>>

Amr Awadallah wrote:
>   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
> suggesting?

I think all that Dhruba is suggesting is that if a developer subscribes
to both -dev and -issues lists then they can use filters to organize
things as they did before when all events were sent to the -dev list.

Doug

+1 for (4)

> -----Original Message-----
> From: Doug Cutting [mailto:[EMAIL PROTECTED]] On Behalf Of Doug Cutting
> Sent: Tuesday, June 23, 2009 11:32 AM
> To: [EMAIL PROTECTED]
> 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

+1 for (4).

Jim Kellerman (POWERSET) wrote:
> +1 for (4)
>
>  
>> -----Original Message-----
>> From: Doug Cutting [mailto:[EMAIL PROTECTED]] On Behalf Of Doug Cutting
>> Sent: Tuesday, June 23, 2009 11:32 AM
>> To: [EMAIL PROTECTED]
>> 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
>>    
>
>

+1 for (4)
On 6/23/09 8:33 PM, "Owen O'Malley" <[EMAIL PROTECTED]> wrote:

I really prefer the current approach, but clearly we need to reach
consensus. Last week we had a case where a developer sent to the users
lists because he thought that dev was reserved for jira traffic. That
is a bad sign. Doug is the most prolific non-jira poster to core-dev
and in 37th place. 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.

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.

-- Owen

+1 on (4)
I want to see all updates to the project without browsing the jira,
which is not particularly friendly for tracking latest changes.
And email filters worked well for me if I need to filter anything out.

--Konstantin

Jim Kellerman (POWERSET) wrote:
> +1 for (4)
>
>> -----Original Message-----
>> From: Doug Cutting [mailto:[EMAIL PROTECTED]] On Behalf Of Doug Cutting
>> Sent: Tuesday, June 23, 2009 11:32 AM
>> To: [EMAIL PROTECTED]
>> 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
>
>