> > > something rational.  Multiple implementations of the same identical
> > > thing is a waste of talent and time.
> > 
> > Code doesn't just grow on CVS trees ;-). 
> 
> And the way this is going, there won't be 'trees' plural, just one
> enourmous one. :)

Geir, you have my vote for multiple CVS trees ( whenever it makes sense
and/or the commiters working on a component just asks for it ). I also
agree with you that for a productized components that grows it may be
better to have separate tree ( and it already happened - I know a little
tool in jakarta-tools that now has it's own cvs :-)


> > In this hypothetical, obviously
> > somebody thought it was worthwhile, or it wouldn't exist. But, none of
> > this is anything we can predetermine. When there is an actual codebase
> > on the table, we can make an actual decision, and have an actual vote.
> 
> Of course, but I thought the point here is to get the basics
> straightened out now before we propose.

+1 - I think the basic here is that we can't decide for others or force
a solution for all cases.

And I agree that the basics must be clear - and the essential one is that
nobody should try to impose his "right way" on others - "there are more
ways to do something".


> Because, (in my head),  as Agora would be organizationally a peer to all
> other 'productized compoenents', all Agora must do is stick to it's
> charter (open incubator) and it is free to do that in any way the
> committers of the Agora project see fit.  Since it seems that the plan
> is that every Jakarta committer would be an Agora committer, anything
> could, would and should happen. 

To make it clear - since I noticed people start miss-interpreting Agora.

The goal of Agora ( that I have in mind ) is not to be a place where
anyone can do anything. The goal is to be a "safe place" where 
"more ways to do something" is the default and where projects may share
code without the current tensions and develop it in common.

In order to achieve that ( tension-free ) goal I am proposing that
"ownership" of the agora is shared among all projects, and each component
in agora can be started by any project ( without any restriction - if the
code was good for the project and acceptred by it's commiters, it's ok for
agora ). I.e. - no bariers for entry, they don't have to justify why their
way to do it is valid, even if other projects believe it should be done 
otherwise or it's duplicated.

( but this rule is not proposed for "anyone can do anything" - that may be
a by-product, and I don't think it is bad, but it's not the goal of agora)

And the other rule ( that for each component, control is shared among
projects using it ) is intended to solve tensions like the ones between
tomcat and catalina ( i.e. a group/project feeling "ownership" of a
component that is supposed to be shared ) - this rule should make it
possible that after multiple components doing the same thing are present,
project can merge them and choose among them, again without the feeling
of "that's mine and this is yours" - you use it, it's yours too, you can't
claim "your component brakes my code" anymore. 

So to make it clear - the agora ( component of commons ) is inteded to
promote exchanges between projects, with the secondary goal of creating
great code by sharing resources and ideas on a greater scale. 

It's not that agora will have some "random" code - almost all code in
agora will be part of at least one project, i.e. used in real-world
production systems.

For example, if Craig agrees to try again to share XmlMapper, that
component is used and tested as part of quite a few betas and releases of
tomcat and catalina.  If we get to share "gtest" - you have something used
in at least 3 projects, part of tomcat, watchdog and catalina. 

Another step might be to productize some of them ( as standalon )- but
can't commit for this ( I know my time resources, and I'm not that
interested )

Costin 

Reply via email to