FAQ
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

Search Discussions

  • Raghu Angadi at Jun 22, 2009 at 10:19 pm

    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.
  • Doug Cutting at Jun 22, 2009 at 10:39 pm

    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
  • Amr Awadallah at Jun 23, 2009 at 12:36 am
    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
  • Owen O'Malley at Jun 23, 2009 at 3:04 pm
    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
  • Raghu Angadi at Jun 23, 2009 at 3:51 pm
    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
  • Doug Cutting at Jun 23, 2009 at 6:32 pm

    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 at Jun 24, 2009 at 3:40 am
    +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
  • Dhruba Borthakur at Jun 24, 2009 at 5:47 am
    +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 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
  • Jeff Hammerbacher at Jun 24, 2009 at 6:59 am
    +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 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 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
  • Nigel Daley at Jun 24, 2009 at 4:53 pm
    +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 would like to
    process-in-depth.

    -dhruba
    On Tue, Jun 23, 2009 at 8:39 PM, Amr Awadallah 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
  • Steve Loughran at Jun 25, 2009 at 1:15 pm

    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
  • Jakob Homan at Jun 26, 2009 at 12:26 am
    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
  • Amr Awadallah at Jun 26, 2009 at 5:05 pm
    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
  • Doug Cutting at Jun 26, 2009 at 5:36 pm

    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 at Jun 26, 2009 at 5:40 pm
    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
  • Doug Cutting at Jun 26, 2009 at 5:49 pm

    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
  • Ted Dunning at Jun 26, 2009 at 5:54 pm

    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. (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'
  • Amr Awadallah at Jun 26, 2009 at 6:01 pm
    +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 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'
  • Owen O'Malley at Jun 27, 2009 at 3:20 am
    Of course the 4' is much closer to my choice #2, which makes me happy too. +1
  • Philip Zeyliger at Jul 1, 2009 at 5:08 am
    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)" <jira@apache.org>
    becomes
    "George Porter (JIRA)" <George.Porter.JIRA.@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 .
  • Ted Dunning at Jun 26, 2009 at 5:37 pm
    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 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
  • Doug Cutting at Jun 26, 2009 at 5:45 pm

    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
  • Amr Awadallah at Jun 24, 2009 at 4:32 pm
    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 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 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
  • Raghu Angadi at Jun 24, 2009 at 5:20 pm
    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 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 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
  • Doug Cutting at Jun 24, 2009 at 5:22 pm

    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
  • Jim Kellerman (POWERSET) at Jun 24, 2009 at 5:56 pm
    +1 for (4)
    -----Original Message-----
    From: Doug Cutting 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
  • Konstantin Shvachko at Jun 24, 2009 at 6:40 pm
    +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 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
  • Jim Kellerman (POWERSET) at Jun 24, 2009 at 6:48 pm
    +1 for (4)
    -----Original Message-----
    From: Doug Cutting 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
  • Hemanth Yamijala at Jun 25, 2009 at 4:56 am
    +1 for (4).

    Jim Kellerman (POWERSET) wrote:
    +1 for (4)

    -----Original Message-----
    From: Doug Cutting 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
  • Nigel Daley at Jun 25, 2009 at 6:43 am
    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 <yhemanth@yahoo-inc.com>
    Date: June 24, 2009 9:55:47 PM PDT
    To: <core-dev@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 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
  • Doug Cutting at Jun 26, 2009 at 5:37 pm

    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
  • Devaraj Das at Jun 25, 2009 at 6:39 am
    +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 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

Related Discussions

People

Translate

site design / logo © 2022 Grokbase