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)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=message-id:date:from:user-agent:mime-version:to:subject:
	references:in-reply-to:content-type:content-transfer-encoding;
	b=H/emzFh2kIQ9D9o1e6p7Gh7V0qFa5mo8GRmteJ+GKBPJMhTmbJD9nJz1k4UnH7yZ
Message-ID: <4A441561.8060407@yahoo-inc.com>
Date: Thu, 25 Jun 2009 17:25:05 -0700
From: Jakob Homan <jhoman@yahoo-inc.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
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

Another option, which I've used extensively, is to make use of the rss 
feeds JIRA provides for all filters, issues lists and 
contributors/commitor actions.  I have separate rss feeds for added 
recently, resolved recently and blockers.  This allows me to track these 
events without crowding my email client and then watching the ones of 
interest.  Pretty much everything on the main project page has an rss 
version of it.  doesn't go down to the commit level, but rss feeds 
provide a very customizable view.  If even more trickery is required, 
Yahoo! Pipes should be able to create whatever you need.

-Jakob
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
>