> I guess I don't understand why the util subproject is
> a special case. If I'm not allowed to vote on the
Because all projects will depend on it.
If you don't want your library shared - don't place it in
the shared repository.
> Servlet API, why can Servlet API committers vote on my
> library? Let's not start rewriting the rules, let's
> just write some good software. If you really want a
> stake in my library, monitor the mailing list, make a
> contribution, and prove that it works. Giving a
> non-contributor voting priveleges is contrary to the
> Jakarta meritocracy. I'm willing to entertain the
First, it's not your library - it's ASF library
( that's the licence - when you contribute the code it
becomes ASF code, it's no longer "yours" ).
And it's not about non-contributors - it's all about
getting jakarta contributors a vote in the shared code.
You don't want your code shared with other projects -
don't place it in library. You can already develop
whatever components in existing projects - and you
can document them, build, etc.
And it is meritocracy - everyone in jakarta made contributions
to ASF and jakarta in individual jakarta projects.
As long as we share a single PMC ( and ASF treats jakarta
as a single entity ) it is supposed that we are
part of a single community, so we can share at least
one repository - and that doesn't change any rules.
> notion of opening access to the whole Jakarta project,
> but _not_ if only the util subproject is open.
That would be great - but it seems there is enough oposition
to opening _one_ ( and one that doesn't have any code in
it anyway ). If this works out we may see fewer bariers between
projects.
If you feel the code is yours and you don't want it
shared among all jakarta commiters, but only in a sub-group -
keep it in the project space.
Costin
