Mailing-List: contact commons-process-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: commons-process@jakarta.apache.org
Date: Tue, 19 Feb 2002 12:22:42 -0800 (PST)
From: <costinm@covalent.net>
To: <commons-process@jakarta.apache.org>
Subject: Re: Adding a committer : Catch-22
In-Reply-To: <B89818BD.11108%geirm@optonline.net>
Message-ID: <Pine.LNX.4.33.0202191209220.11491-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Feb 2002, Geir Magnusson Jr. wrote:

> > IMHO commons is supposed to be a repository for code
> > that is used by multiple jakarta projects - not
> > a dump or a sourceforge-style repository where
> > any cool idea can be implemented.
> 
> Well, I remember the former as one of the drivers of the project, but the
> latter is where we are.
> 
> Commons-logging is an example - it was created entirely within commons.

But with at least jakarta-struts and possibly other projects 
'signed up' as users ( tomcat's j-t-c/jk will use it shortly, etc ).

If a commons component is not used in any other jakarta project,
what's the point and what does it have to do with the 
commons in the first place ?

If you have something that is not curently needed in any 
project - the right solution is to request a new top-level
project, not to dump it in commons as a workaround for
the current rules. 


> > I don't see any catch-22 here - I think of sandbox as
> > a ( common ) 'extension' to all jakarta projects.
> > If a project is indeed usefull in at least a jakarta project
> > ( or more ), and someone sends patches and contributions
> > to that sandbox component, I'm sure the commiters from
> > the jakarta project that is interested in the sandbox
> > component can vote and make the contributor a commiter
> > - either on the project or on commons.
> 
> That works and solves the problem.  However, it puts a restriction on
> Commons we don't currently have.

There is no restriction - commons is a jakarta project and the
normal rules apply - vote, etc. What I'm saying is that if
a sandbox or commons component is indeed usefull to another
jakarta project, it's quite easy to get the review and votes
that are needed ( since most jakarta projects have people 
who are in commons - or it's easy to get them in ).

Even in the unlikely event other commons people will vote 
against, the code can still be released and people 
added as part of the other project.


> > If the sandbox component doesn't have at least 3
> > commiters and is not used by at least one jakarta project,
> > I don't think it should be included in commons or
> > get to add more commiters - there's not enoguh review
> > nor interest.  
> 
> I agree up to the 'one jakarta project' bit, but only because I have gotten
> used to the idea of standalone components, not that I disagree
> fundamentally.

Standalone components that are _used_ for something in jakarta. 


> > In general, use by at least one jakarta project should
> > be a major factor in getting something in jakarta-commons.
> 
> And this is an interesting aspect : do you consider AltRMI a part of Avalon?

I don't know - I'm not an avalon commiter. If AltRMI solves a problem
for Avalon and avalon people would be interested to include the 
code with avalon ( and that means support it, etc ) - then there's
no problem. They can do it right now, and they can add new commiters
easily in avalon and probably in commons, and they can even make 
a release ( as an avalon component ), regardless of commons.


Costin