> 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
