> > (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
