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
