avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject RE: [PROPOSAL] Adopting JIRA
Date Wed, 14 Jan 2004 22:37:12 GMT


> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> 
> Here I disagree.  There are multiple cases where an API artifact does
> not change version bu the implementation artifact does.  For example,
> the change made to the Avalon Meta package impacts the meta tools
> project and the plugin project.  The api remains unchanged.  I think we
> should avoid a "group" version model as this move us away from the
> reflection of notion of major and minor version changes that correlate
> with interface/implementation changes.

<snip/>
 
> If JIRA supports nested categories I would agree with.  If it does not
> then I think we need multiple categories simply because of the number of
> independence versionable projects.

Okay, so that means we'll have:

Category: Avalon

 avalon-extension              
 avalon-framework              
 avalon-meta                   
 avalon-repository           
 logkit                   <-- or should these 4 be separate categories?     
 merlin                   <--|     
 phoenix                  <--|     
 fortress                 <--|


Category: Cornerstone
            
 cornerstone-connection-api    
 cornerstone-connection-impl   
 cornerstone-datasources-api   
 cornerstone-datasources-impl  
 cornerstone-scheduler-api     
 cornerstone-scheduler-impl    
 cornerstone-sockets-api       
 cornerstone-sockets-impl      
 cornerstone-store-api         
 cornerstone-store-impl        
 cornerstone-threads-api       
 cornerstone-threads-impl  

Category: Excalibur
    
 excalibur-compatibility       
 excalibur-component           
 excalibur-configuration       
 excalibur-datasource          
 excalibur-event               
 excalibur-i18n                
 excalibur-instrument-manager  
 excalibur-instrument          
 excalibur-lifecycle           
 excalibur-logger              
 excalibur-monitor             
 excalibur-naming              
 excalibur-pool                
 excalibur-sourceresolve       
 excalibur-thread  

That's a LOT of projects to administer and, to me, it seems like overkill.
I mean, that puts something like excalibur-datasource on the same level as
Merlin and Phoenix.  There are still project components that can handle a
lot of this.  For example, can't we at least have the Cornerstone API and
IMPL parts just be components of the same cornerstone-xxx project?  I guess
that could mess up the versioning.  Grrr.  If that's what we should do, then
that's what we should do, but it seems inefficient to me.  I've used JIRA a
bit for a couple other projects, but I'm no expert.  Does someone with some
experience (Serge?) want to offer some perspective on this?

I'll let the proposal settle down and we'll look at sending the request to
infrastructure in the next day or two.

The default view of JIRA's front page is going to look pretty busy. :)

> It's worth dragging out because whatever we setup is something we are
> probably going to live with for some time to come.

Agreed.

J. Aaron Farr
  SONY ELECTRONICS
  DDP-CIM
  (724) 696-7653

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


Mime
View raw message