Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <400385E7.7020807@discursive.com>
Date: Mon, 12 Jan 2004 23:45:11 -0600
From: Tim O'Brien <tobrien@discursive.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.5) Gecko/20031014 Thunderbird/0.3
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [codec] [vote] JIRA
References: <NBBBJGEAGJAKLIDBKJOPKEOCGIAB.noel@devtech.com>
 <40037A79.9070608@discursive.com> <40037FA8.1060704@steitz.com>
In-Reply-To: <40037FA8.1060704@steitz.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Phil Steitz wrote:

>
> What exactly does Jira have to do with release management and site 
> publishing?  I am asking out of ignorance here.  I thought Jira was an 
> issue tracker.
>

Issue tracking is central to cutting quality releases, and communicating 
direction.  Jira is more than issue tracking, IMO it includes feature 
planning and the ability to talk about the next few releases.  Something 
I think a lot of commons components could use is a long-range vision.  
Think about Commons Math.  I think it would have been easier from the 
start if there had been an idea of a roadmap for the first release.   
Also, it would be nice to have a sense of a longer-term goal for Math.

People who take on the responsibility of release manager have to ensure 
that all bugs are addressed, and a changelog is created.  In addition, 
because our process relies on the dev mailing list, it usually takes a 
series of emails to convey what the plan is for the next release.  A 
"release manager" magically appears and gives some direction to a 
project.  A release will be cut when the following conditions are met, 
etc.  The problem with this model is that (many) of the projects in 
Commons rely on the same person to act as a release manager.  If that 
one person decides to move on, or stop paying attention, you reach a 
situation where no one necessarily knows what the "direction" of a 
project is.  This has happened to a number of projects that didn't make 
it out of the sandbox, and IMHO, to a number of projects in Commons 
Proper. 

To illustrate this, take Betwixt.  Robert B. Donkin had rewritten major 
portions of the code, and subsequently moved on.  A production release 
hadn't been cut, and well, the project is still in a strange limbo.  
This situation would have been different had we a simple "roadmap" of 
planned features for the next 3 releases, and someone paying attention 
to these components.  Further, if we had done some good communicating 
about what to include in the next release, we probably could have 
rousted some programmers to come and help out. 

Sure, we could continue to use Bugzilla, but version numbers are not 
isolated for Commons Components, and, frankly, I don't see a lot of 
people knocking down the door here to help out.   I want an issue 
tracker where we can reasonably expect able volunteers to stumble upon 
some tasks.    Essentially, I see conversation increasing at J-C, but 
participation lagging.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org