[RT] Commons is not a Dumping Ground

[Leo Sutic <le...@inspireinfrastructure.com>]

All,

a couple of times we have found that some utility code we needed
simply wasn't available. The solution has been to write our own.
Excalibur/Concurrent, Excalibur/CLI and others have been created
to satisfy a need that later on was filled by some other package.
In many cases, however, there never were another package - 
Excalibur/Extension, for example, have no other, properly licensed
counterpart we can switch to. 

The solution is those cases have been to move the code to some
other project - most often Jakarta Commons, and lately Spice. The 
problem here is that neither Commons nor Sopice are somewhere you 
can just dump code and walk away. The other problem is that there 
is some effort involved in the move - import declarations and so 
on must be changed, dependent jar files changes etc. For Spice,
you may get licensing issues as well.

I therefore propose that any utility code be developed in
the Jakarta Commons Sandbox, as soon as possible in the code's
life.

   "We do have an open-door policy for the sandbox CVS 
    (jakarta-commons-sandbox). Any Jakarta committer is 
    entitled to write access to the sandbox upon request, 
    no vote required, no questions asked. Just subscribe 
    to jakarta-commons-sandbox, and request authorization."

That would allow the following:

 + We would still have access to the code (which we don't
   have if we just give it to a Commons project, unless
   we're Commons committers).

 + No "dumping" of code.

 + We can use the package name org.apache.commons.*, so
   binary and source compatibility is *right* from the 
   start.

We also gain exposure.

For example, Excalibur/Extension could move to 
Commons/Sandbox. If it is useful, I'm sure it can become
a "proper" non-sandbox project.

/LS


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

Re: [RT] Commons is not a Dumping Ground

[Berin Loritsch <bl...@apache.org>]

Leo Simons wrote:
> good overview, good points, good compromise, one caveat, additional 
> comments.
> 
> I would add that it is not a *requirement* that we only use utility code 
> which is developed at apache. For example, qdox, xdoclet, isorelax, 
> spice-jndikit.
> 
> It is just the goal that generic utility code developed by avaloners is 
> developed/nurtured in an appropriate place at apache (note the use of 
> the fact that avaloner --extends--> apache person). What is an 
> appropriate place depends on the (expected) size and scope of the 
> project. Appropriate places may indeed include jakarta-commmons-sandbox, 
> incubator (which is where altrmi went), and I would assume in the future 
> also commons.apache.org will become a nice place to work on code.
> 
> For really small pieces of utility code (stuff like excalibur-i18n, 
> which is just two classes), I think it is also okay if this lives as 
> part of some other package, for example, it is not neccessarily bad if 
> it were a part of phoenix. Any package has some "utility code", and it 
> is not always a requirement to seperate it out.

I am using Excalibur i18n for the D-Haven GUIApp project, and would
prefer that it didn't get merged into Phoenix.


-- 
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock


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

Re: [RT] Commons is not a Dumping Ground

[Leo Simons <le...@apache.org>]

Nicola Ken Barozzi wrote:
> Leo Simons wrote, On 18/04/2003 11.33:
>>
>> Maybe we can get the jakarta people to extend "any jakarta committer" 
>> to be "any apache committer" and open up their sandbox further.
> 
> They already had voted on it months ago for the sandbox, but nothing was 
> finalized. If you bring it up there I'm confident it will have the same 
> result.

just did :D

- Leo



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

Re: [RT] Commons is not a Dumping Ground

[Nicola Ken Barozzi <ni...@apache.org>]

Leo Simons wrote, On 18/04/2003 11.33:
...
> Leo Sutic wrote:
> 
>>  + We would still have access to the code (which we don't
>>    have if we just give it to a Commons project, unless
>>    we're Commons committers).
> 
> 
> the big caveat: this is not always neccessarily true. People who are 
> avalon committers but not jakarta committers have no access. The 
> downside of us becoming toplevel is that it is no longer true avalon 
> committter --extends--> jakarta committer.
...
> Maybe we can get the jakarta 
> people to extend "any jakarta committer" to be "any apache committer" 
> and open up their sandbox further.

They already had voted on it months ago for the sandbox, but nothing was 
finalized. If you bring it up there I'm confident it will have the same 
result.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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

RE: [RT] Commons is not a Dumping Ground

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> I would add that it is not a *requirement* that we only use 
> utility code which is developed at apache.

Of course! What we use should be decided on a case-by-case basis.
 
> Any package has some "utility code", and it 
> is not always a requirement to seperate it out.

Again, we take it as it comes. What I'm concerned with are
packages like Excalibur/Concurrent and Excalibur/Collections.
Both have been moved out, but they provide good examples of
the type of utility code I'm thinking about. Immediately:
Excalibur/Extension -> get it to sandbox and seek synergy with
Commons/Discovery.
 
> Leo Sutic wrote:
> >  + We would still have access to the code (which we don't
> >    have if we just give it to a Commons project, unless
> >    we're Commons committers).
> 
> the big caveat: this is not always neccessarily true. People who are 
> avalon committers but not jakarta committers have no access.

I think this is a holdover from the time when Jakarta == All Java dev
at Apache. Going according to the spirit of the requirement, I don't
think this is a problem. I don't think Peter D will have any problems.

> I've made matters more complex again, haven't I? ;)

I don't think so.

/LS


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

Re: [RT] Commons is not a Dumping Ground

[Leo Simons <le...@apache.org>]

good overview, good points, good compromise, one caveat, additional 
comments.

I would add that it is not a *requirement* that we only use utility code 
which is developed at apache. For example, qdox, xdoclet, isorelax, 
spice-jndikit.

It is just the goal that generic utility code developed by avaloners is 
developed/nurtured in an appropriate place at apache (note the use of 
the fact that avaloner --extends--> apache person). What is an 
appropriate place depends on the (expected) size and scope of the 
project. Appropriate places may indeed include jakarta-commmons-sandbox, 
incubator (which is where altrmi went), and I would assume in the future 
also commons.apache.org will become a nice place to work on code.

For really small pieces of utility code (stuff like excalibur-i18n, 
which is just two classes), I think it is also okay if this lives as 
part of some other package, for example, it is not neccessarily bad if 
it were a part of phoenix. Any package has some "utility code", and it 
is not always a requirement to seperate it out.

Leo Sutic wrote:
>  + We would still have access to the code (which we don't
>    have if we just give it to a Commons project, unless
>    we're Commons committers).

the big caveat: this is not always neccessarily true. People who are 
avalon committers but not jakarta committers have no access. The 
downside of us becoming toplevel is that it is no longer true avalon 
committter --extends--> jakarta committer. Hmm. In a sense spice is in 
fact more open from the view of the avalon committer base as Peter has 
said anyone who wants access will get it. Biting the bullet and ducking 
at the same time: Pete was suspended from all ASF projects, and I don't 
think he was reinstated as a jakarta committer. In a sense, moving 
things to jakarta commons will enable just about any avalon committer 
but Pete to work on things. Icky issue. Maybe we can get the jakarta 
people to extend "any jakarta committer" to be "any apache committer" 
and open up their sandbox further.

The downside with projects like spice or codehaus is that it is not 
crystal clear how decisions are reached there, so it is not clear what 
the relationship between "access" and "influence" is. IOW, what happens 
if I move extension to spice, and a spice developer makes a change there 
which is incompatible with merlin's needs for the package? Avalon is 
giving up control over things when moving them out of avalon. Moving 
things out to another apache project still answers these kinds of 
questions (we all know how decisions are reached at apache and how to 
behave according to the general asf structure, and that this process is 
compatible with our own), moving things out to a nonapache project 
raises the extra question mark.

>  + No "dumping" of code.
> 
>  + We can use the package name org.apache.commons.*, so
>    binary and source compatibility is *right* from the 
>    start.

big pluses.

There is perhaps also the desire to keep what is essentially good code 
owned by the ASF in a place where it is developed by the ASF. Apache is 
one of the highest-exposure places for a piece of code, for good reason, 
and we might want to extend that benefit to code. This is one of the 
reasons for example why I would rather see altrmi.apache.org than 
altrmi.sourceforge.org: it is ASF code developed by ASF people in an ASF 
manner under the ASF license.

I've made matters more complex again, haven't I? ;)

- Leo



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