On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
> > > (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> > > work on whatever they like there. No questions asked.
> > >
> > > (2) A codebase developed in the sandbox can't be released to the public
> > > from the sandbox. To release the code to the public, you would have to
> > > move it to another Jakarta CVS, where a subproject could vote to release
> > > it.
> > >
> > > The sandbox could just as easily be part of the Jakarta backbone site,
> > > but it making it part of the Commons proposal seemed like a convenient
> > > way to set it up.
> > >
> >
> > The "sandbox" part, and not being available to the public, was the part I
> > understood. However, point 20 of the revised proposal reads (caps
> > identify the part I'm having a problem with):
> >
> > A cvs repository will be available to all Jakarta
> > committers as a sandbox for new packges. Before
> > release to the public, the sandbox package must be
> > accepted to the commons, OR SPONSORED BY ANOTHER
> > JAKARTA SUBPROJECT.
> >
> > What does "sponsored by another Jakarta subproject" mean? It looks from
> > the wording of 20 that you can bypass the acceptance to the commons that
> > is described in 17. Is that actually the case?
>
> That was the intention - or at least what I proposed.
>
> The idea was that a project can start using a sandbox package - in this
> case when the project is preparing for a release it needs to tag the
> workspace and support a specific version of the common.
>
> Say we have a "thread pool" package, developed in sandbox space, and maybe
> used in common by few jakarta projects. And one of the projects is
> preparing for a release. At this point it can request a release of each
> component it uses - so the project release will depend only on stable
> code. This shouldn't be dependent on library aproval.
>
> ( well, a jakarta project can decide to release whatever it wants as part
> of that project - but IMHO it's important to make this clear and explicit
> )
>
> Costin
>
>
Hmm, it seems to me that this is going to create ambiguity about the code
in the sandbox, because there will be (at least) two flavors:
* Code being experimented with, played with, evaluated, but not
yet used anywhere (i.e. what I had understood the sandbox was for).
* Code being experimented with, played with, evaluated, AND released
as part of another subproject, even though it has not been proposed
to (or accepted by) Commons.
It would seem better to me that a subproject wanting to use sandbox code
in a release should do one of the following:
* Propose the code to Commons, with the associated willingness to
support it.
* Take the code to be released back into its own CVS repository
until such time as it is proposed to, and accepted by, Commons.
This is also more consistent with the restriction in (1.5.1) that sandbox
code cannot be "released to the public" until accepted by Commons. To me,
including that code in a subproject release counts as "released to the
public".
Craig
