Of course the 4' is much closer to my choice #2, which makes me happy too. +1
+1 for 4' :)
-- amr
Ted Dunning wrote:
On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting 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
On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting 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. (Closi
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 op
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 mes
> 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).
Thank
Nigel Daley wrote:
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.
The first step is creating the -issues lists.
I just filed a Jira for t
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 wrote:
> For ex
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?
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 t
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 em
> 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
e 24, 2009 9:55:47 PM PDT
To:
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
+1 for (4)
On 6/23/09 8:33 PM, "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 p
+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'M
+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:
&g
-
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 domi
+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:
&g
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 dev
What I use to filter mails for jiras I am more interested in
(watching/created/assigned...) :
from : j...@apache.org
to : rang...@yahoo-inc.com
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 wo
+1 for (4)
On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur
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 woul
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 wrote:
> +1 for (4).
>
> This means th
+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
+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 Awada
+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 thos
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 thi
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 reac
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 pl
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
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
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 wat
We now have 3 subprojects common, hdfs, and mapreduce that replace the
old core. Their urls are:
Common:
core-{user,dev,commi...@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-{u
32 matches
Mail list logo
