See intermixed.
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
> On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> >
> > 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:
>
> I agree with that - I'm also uncomfortable with the current wording ( and
> the fact that "agora" + "playground" = "sandbox").
>
>
>
> > (1) New experimental code that is not available to the public (and
> > is not subject to releases or versioning).
>
> This is not my concern, and it was not part of my proposal for agora - we
> can have this as "jakarta-playground" if we want, or each commiter can use
> a proposals/ in his project.
>
> But we can use jakarat-agora/proposals or something for this kind of
> code - it'll be in the same situation with experimental code that is
> checked into any jakarta project.
>
> The experimental code is experimental - when it starts to be used in a
> stable release of a project it's no longer experimental.
>
Agreed ... hence the need for a clear distinction in how non-experimental
code is organized and handled.
> > (2) Code that has been released as part of a subproject (but does
> > not have a released state of its own).
>
> That's what I'm interested in and what Agora is supposed to do.
> Put this code in a place where other projects can share and use without
> any barier.
>
Costin, how is your view of this use case different from (3) below? Why
would it not just be proposed to the Commons, and set up with its own
formal release structure?
Even if only one subproject makes use of it initially, making the code
available for reuse seems to be the whole point of why we are here.
> The idea that "all jakarta commiters are commiters in agora" was intended
> exactly for that - we share components, we agree other projects and
> commiters with different goals and opinions will have the same right with
> us, even if we are the original authors. It was not intended as "we are
> all commiters, we can play and do what we want".
>
>
> > (3) Code that has been accepted into the Commons (and therefore has
> > its own release schedule and versioning).
>
> That's again well defined, and it's a clear part of the library.
>
> >
> > 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 (b) - or
>
> (c) Rename "sandbox" to "agora", make clear that experimental code is
> allowed using the same rules that are used for any other jakarta
> project. We can have a jakarat-agora/sandbox directory for this kind of
> experiments if someone really wants that.
>
Changing only the name doesn't resolve my issue with two use cases in one
repository.
> The goal is to keep the code in a common place so more projects
> can cooperate on it, and that's why we need a common repository where all
> projects have equal access.
>
> We want to promote comunication between projects - not to copy code back
> and forth.
>
> Of course, some code will mature and become part of "commons" ( with it's
> own maintainers), but some code will continue to be developed and
> maintained by the projects that are using it.
>
Why can't they do that in the Commons? Those packages are going to be
maintained, and enhanced, and released, as well. What's the difference?
>
> Costin
>
>
Craig