Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A44FF7E.2040705@cloudera.com>
Date: Fri, 26 Jun 2009 10:03:58 -0700
From: Amr Awadallah <aaa@cloudera.com>
Organization: Cloudera, Inc.
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: core-dev@hadoop.apache.org
Subject: Re: more information about project split
References: <C2563474-EB2D-4A17-AF16-334890FB4D5B@apache.org>
	 <4A400358.3070703@yahoo-inc.com>
 <4A400827.3090409@apache.org>	 <4A402377.50107@cloudera.com>
	 <3A42F667-2FB8-42BC-A77D-9A8B1A906171@apache.org>
	 <4A411FB3.3010004@apache.org>
 <4A419FDC.6090304@cloudera.com>	 <4aa34eb70906232247h16196524gece90ff1e88d4ad5@mail.gmail.com>
 <c9118d4c0906232359hbdbc473v66a64e63024d2307@mail.gmail.com>
 <4A437851.8040500@apache.org>
In-Reply-To: <4A437851.8040500@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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