On Wed, 14 Mar 2001, Ted Husted wrote:
> [EMAIL PROTECTED] wrote:
> > The current rule is that a jakarta project can "sponsor" a component in
> > the sandbox/agora. The components in the sandbox/agora are developed by
> > jakarta commiters, and may included in multiple jakarta projects - so
> > probably they have a higher quality standard and more review than
> > most components that will be developed and maintained by 3-4 library
> > developers.
>
> How does the code get out of the sandbox and into the multiple products?
Each product can take it outside of the box and include it.
> Before when we talked about it being released as part of the product, I
> thought that meant the code would be placed in the product's CVS, and
> made part of the product's distribution. That's what I meant by
> sponsored.
That's one way.
Or the project may tag all the components that it uses and build a
snapshot ( say threadpool.jar ) and then include this jar in the project
distribution.
It can do that either by combining it in the project jar.
Or the project may decide it's better to include a separate jar, and maybe
later on, if the component improves or gets bugfixes, the project may
choose to tag again the workspace and release an "update" for that
component.
There are other choices - but it's the project that is using the component
that makes the decision about what's best for it.
Most of the time the components are not tightly-coupled in the project -
and releasing updates is a very valid choice for a project. In which case
it may need to make the component available as a separate (
"update" ) jar.
>
> For the Commons, each package would have a separate root branch, with
> it's own build, along with ready-to-run JARs, that could be downloaded
> via the catalog.
>
> Is that what you planned to do with Agora?
No - I didn't planned anything with Agora. Or I planned that no plan
should be pre-set for Agora - the component can be packaged as a separate
entity and proposed in the commons, or jakarta projects may decide a
distribution mechanism that fits it's goals.
What is important is that the rules for Agora should be open to the needs
and decisions of jakarta projects.
IMPROTANT. That doesn't mean "anyone" can release components or the
quality will be affected - this is clearly specified that a jakarta
project can vote and release different components that it co-develops with
other projects.
A vote in a project ( like tomcat or ant ) is as good and involves as much
responsibility as a vote in the library project.
IMHO a component that is released this way will have more review and
support than a regular library - since people from other projects will
monitor this as well.
> I believe that there has to be a clear, documented vote before we can
> release the code under the Apache brand.
>
> So after getting the build for Tomcat, do I then have to get the build
> for the entire sandbox, or would the tagged branch be available
> separately?
Tomcat commiters will decide what's best in each case, and chose what's
easier/better for tomcat users.
> If the tagged branch is available separately, then can one or more
> of the subprojects vote specifically on that branch before it is
> released to the public?
I suppose so.
>
> Part of the problem is that I don't grasp the mechanics of Agora.
The mechanics are simple - make it as open as possible to the needs of
jakarta subprojects. Don't force any pre-set solution, but let them choose
how to use the commons. After all, we are talking about clearly defined
entities that have the right to choose on their own.
Costin
