hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: more information about project split
Date Thu, 25 Jun 2009 13:14:57 GMT
 > 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...


View raw message