+1 - I can say I agree 100%.
Regarding peer review and "releasing" - if the component is used in a
product, it'll be released as part of the product.
If it is productized and released as stand-alone - normal jakarta rules
should apply.
In the STATUS file we should list all releases the component is part of,
and a "component status":
- experimental
- not released
- released as part of project foo.x.y
- released standalone
( and of course, my initial proposal that any project should be able to
tag the workspace when they have a release, so they can re-create the
build later and be able to refer to the state of the component when it was
included in the project release ).
Costin
> The incubator CVS is another recurring theme.
>
> We have a good example right now. Geir and some others might like to
> work on a database connection pool. But there's no where in Jakarta land
> they can easily do that now. We can't get a CVS without a proposal, and
> we can't get a codebase without a CVS. (Whither SourceForge ..)
>
> Costin wanted to try this with Jakarta-Util, but the vote tanked.
>
> Personally, I have no problem with everyone being enrolled to the
> library CVS, or enrolled upon request (if they are already a committer).
> My only stipulation would be to encourage an etiquette where people
> added themselves to the Status file before committing to an existing
> package -- so that people feel like they are signing up for something.
> But creating new, test packages would be fair game.
>
> The only thing we have to watch for is that there is some type of peer
> review before a package goes into public distribution under the Apache
> name. Jakarta != SourceForge. This is where a proposal and/or vote would
> come in. But, anyone can check a revolution out of the CVS, we're just
> not saying it's ready for prime time.
>
> And, for the purposes of this proposal, you're a committer here ;-) Your
> vote counts as much as any other on this.
>
>
> -T.
>
> David Weinrich wrote:
> > So once again please consider this option:
> >
> > * One project with two parts, a sandbox and a library.
> > * The sandbox is low barrier of entry and informal, while staying within
> > the goals and guidelines of the jakarta project.
> > * The library has well defined standards of documentation and testing and
> > is a repository for *stable* components.
> > * At the point where a component is ready to move from the sandbox into
> > the library, a mini-proposal is submitted to the list, with a list of the
> > people who will become the caretakers of the component.
> >
>
