You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Owen O'Malley <om...@apache.org> on 2009/06/22 08:44:11 UTC
more information about project split
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
Re: more information about project split
Posted by Raghu Angadi <ra...@yahoo-inc.com>.
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
Re: Fwd: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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 this:
https://issues.apache.org/jira/browse/INFRA-2114
Doug
Fwd: more information about project split
Posted by Nigel Daley <nd...@yahoo-inc.com>.
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 <yh...@yahoo-inc.com>
> Date: June 24, 2009 9:55:47 PM PDT
> To: <co...@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
>>>
>>
>>
>
Re: more information about project split
Posted by Hemanth Yamijala <yh...@yahoo-inc.com>.
+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
>>
>
>
RE: more information about project split
Posted by "Jim Kellerman (POWERSET)" <Ji...@microsoft.com>.
+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
Re: more information about project split
Posted by Konstantin Shvachko <sh...@yahoo-inc.com>.
+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: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
>
>
RE: more information about project split
Posted by "Jim Kellerman (POWERSET)" <Ji...@microsoft.com>.
+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
Re: more information about project split
Posted by Nigel Daley <nd...@yahoo-inc.com>.
+1 for (4)
On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur <dh...@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 <aa...@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
>>>
>>
>
Re: more information about project split
Posted by Jakob Homan <jh...@yahoo-inc.com>.
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
>
Re: more information about project split
Posted by Philip Zeyliger <ph...@cloudera.com>.
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)" <ji...@apache.org>
becomes
"George Porter (JIRA)" <Ge...@fake.jira.apache.org>
The from address is broken, but I've added a reply-to to
jira@apache.org, 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 .
Re: more information about project split
Posted by Owen O'Malley <ow...@gmail.com>.
Of course the 4' is much closer to my choice #2, which makes me happy too. +1
Re: more information about project split
Posted by Amr Awadallah <aa...@cloudera.com>.
+1 for 4' :)
-- amr
Ted Dunning wrote:
> On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting <cu...@apache.org> 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'
>
>
Re: more information about project split
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Jun 26, 2009 at 10:49 AM, Doug Cutting <cu...@apache.org> 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'
Re: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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
Re: more information about project split
Posted by Ted Dunning <te...@gmail.com>.
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 <aa...@cloudera.com> 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
>
Re: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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
Re: more information about project split
Posted by Amr Awadallah <aa...@cloudera.com>.
> 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
Re: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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
Re: more information about project split
Posted by Amr Awadallah <aa...@cloudera.com>.
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
Re: more information about project split
Posted by Steve Loughran <st...@apache.org>.
> 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
Re: more information about project split
Posted by Jeff Hammerbacher <ha...@cloudera.com>.
+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 <dh...@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 <aa...@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
> >>
> >
>
Re: more information about project split
Posted by Raghu Angadi <ra...@yahoo-inc.com>.
What I use to filter mails for jiras I am more interested in
(watching/created/assigned...) :
from : jira@apache.org
to : rangadi@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 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 <dh...@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 <aa...@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
>>>>
Re: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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
Re: more information about project split
Posted by Amr Awadallah <aa...@cloudera.com>.
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 <dh...@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 <aa...@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
>>>
>>
>
Re: more information about project split
Posted by Dhruba Borthakur <dh...@gmail.com>.
+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 <aa...@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
>>
>
Re: more information about project split
Posted by Amr Awadallah <aa...@cloudera.com>.
+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
Re: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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
Re: more information about project split
Posted by Devaraj Das <dd...@yahoo-inc.com>.
+1 for (4)
On 6/23/09 8:33 PM, "Owen O'Malley" <om...@apache.org> 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
Re: more information about project split
Posted by Owen O'Malley <om...@apache.org>.
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
Re: more information about project split
Posted by Amr Awadallah <aa...@cloudera.com>.
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
Re: more information about project split
Posted by Doug Cutting <cu...@apache.org>.
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
Re: more information about project split
Posted by Raghu Angadi <ra...@yahoo-inc.com>.
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.