Rather than re-invent the wheel, I'd like to start with the Taglibs
model.
Depending on the circumstances, they may propose the tablig to the list
first and then open a whiteboard directory, or, if the code is solid,
open a directory first and then start the discussion.
I believe whether a Commons committer chooses to open a directory in the
Sandbox or the main CVS should be a judgment call. Craig felt the
BeanUtil was solid, and started up in the main CVS without the
super-majority mentioned in the charter. But since he is already a
Commons committer, I'm good with that.
My thinking on the life cycle is:
(0) Someone has itch to write a package.
(1) They bounce it off the Commons list to see how other people feel.
(2) If the feelings are good, they start a whiteboard directory in the
main CVS (Commons Committer) (e.g. BeanUtil), or in the sandbox CVS
(other Jakarta Committer) (e.g. Cactus).
(3) When the package Committers are ready, they propose the package to
the list for a subproject vote.
(4) Repeat (3) as a majority vote for subsequent stable releases.
-Ted.
"Geir Magnusson Jr." wrote:
>
> Ted Husted :
>
> > I would also say that, as a Commons Committer, he can open whiteboard
> > directories in the main CVS now and then call for a vote on the initial
> > release later.
>
> Two issues here:
>
> I] Regarding 'a vote on the initial release', I thought the vote would
> be on making the project into a 'Commons component', not on the
> releasability of that project.
>
> II] Regarding random whiteboard directories under the main CVS :
>
> Can we try to avoid that if possible, and consider the
> jakarta-commons-sandbox CVS as the 'whiteboard' area for
> non-yet-voted-on component source?
>
> There are a few reasons I ask :
>
> 1) The jakarta-commons 'main CVS' are the components that we have all
> agreed are the individual entities that make up Commons. It makes up
> the parts of the Commons project that is supported code with a charter.
> Having arbitrary stuff under a top-level whiteboard would be confusing.
> Of course, each component project can whiteboard to their hearts content
> under their own section of jakarta-commons.
>
> 2) Since we have the sandbox that is equivalent in capability and
> access, keeping the not-yet-approved components there keeps the sandbox
> complete as the place for proposed and embryonic projects.
>
> 3) This will help keep the size of the jakarta-commons main CVS limited
> to that of the supported components. I am afraid that the monolithic
> CVS tree may get ungainly over time as Commons grows, so keeping the
> main CVS limited to the actual supported components may help in this
> regard.
>
> geir
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> Developing for the web? See http://jakarta.apache.org/velocity/
