hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amr Awadallah <...@cloudera.com>
Subject Re: more information about project split
Date Fri, 26 Jun 2009 17:03:58 GMT
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:


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


  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.


-- 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 instead of 
> the external address...
> -steve

View raw message