Ok, I think I need to clarify:
Experimental code can happen in any project, including commons - as part
of a proposals/ directory. Nobody complained so far that they can't do
experiments, and the library wasn't started to provide place for
experimental code, but to create components with a clear goal and
community ( the library side ) and to create a place where projects can
cooperate on common components ( the agora side ).
Given the current confusion I would really like to change the name/scope
of the sandbox and make it closed to experimental code ( as in the
original proposal ) - only code that is contributed from an existing
project should be accepted, at least in the initial stage.
On Wed, 14 Mar 2001, David Weinrich wrote:
> I have to agree with you on this one, the case where a code is in the
> state of (2) above seems to invite problems. What seems to be a decent
> compromise to me is to allow a status to be attached to each a component:
We didn't spend all those weeks of discussion just to come with a
playground for experimental code - anyone can do experiments on
SourceForge or in a proposal directory in any project.
Mixing experimental code in Agora can only create problems and confusion.
> 1) What can be done to prevent the situation Craig describes above, where
> one or more jakarta project(s) use different versions of code from <insert
> name of shared CVS here>?
If the projects are sharing the component ( i.e. they are all equaly
involved in the development of the component ) it's less likely to happen
than in the case when the component is developed outside the projects.
The problem is when there are incompatiblities and you can't use the
latest version - but that's the whole idea behind giving a vote to all
projects that are involved and are using the shared code.
> 2) In what cases would people work together on code, but not want to go
> the extra ten miles to release the code as a 'product' or 'component' ( or
> any other suitable word)?
Tools ? Most of the components are tools that help us construct a product
( like tomcat ). We have goals - and if you get distracted in creating
products out of the tools you use you may not get your main goal.
There are many people who are involved in the library because they want to
create components. And I'm sure many of those common packages will become
top-level components and will get their own maintainers.
But my interest is in sharing code among projects - if the shared code
will be componentized that's great, but it's not the primary goal.
> 3) What should be the criteria for what is considered 'fit for public
> consumption' code?
That's simple to answer - when all commiters of a jakarta project are
happy with a piece of code.
It's a simple vote - and this happens quite often, so no need to worry
about that.
Costin
