See below.
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
> 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.
>
I'm all for setting things up so that people can do what they need. My
discomfort is the current proposal combines three use cases:
(1) New experimental code that is not available to the public (and
is not subject to releases or versioning).
(2) Code that has been released as part of a subproject (but does
not have a released state of its own).
(3) Code that has been accepted into the Commons (and therefore has
its own release schedule and versioning).
into only two places where the code might live:
(A) sandbox - for cases 1 and 2.
(B) commons - for case 3.
I don't like the ambiguity of what code in sandbox means
under this scenario. Alternatives to solve the problem include:
(a) If a project wants to release something that includes code in the
sandbox, it must either get it accepted into commons, or copy the
code back into its own repository.
(b) Add a third reposiory (I guess it would be agora according to the
current vocabulary) for use case 2.
I would prefer we choose (a), although I could live with (b).
> Costin
>
>
Craig
