> > I would also like to ask for something like: if a project is using a
> > component, and none of the project commiters are commiters for the
> > component - the project as a whole should count as a commiter (
> > i.e. should be able to request a temporary freeze, a tag, etc - so a
> > "stable"/"predictible" version of the component can be included ).
> > ( it that's not too much )
There are 2 issues:
1. A project should be able to share some code/components. I don't see
myself using or participating in a library that is not open to all
jakarta projects. And please don't call it library if the books are going
to be selected by "library commiters". Yes, you may have duplication - but
that's far better than having any group of people deciding what is the
"right" way. I don't care how "expert" or good is the group that makes
the selection - the library should be open to all jakarta projects
that want to share something, and the users should decide for themself
what to read.
2. If a component is going to be shared, and more than a jakarta project
is going to use it - I would like all projects that are using the
component to have at least the right to tag the workspace and veto/fork if
a change is braking their code. Personally, I will not use a component in
tomcat if that component is going to change without any control from
tomcat - I would rather rewrite the component than risk the stability of
the project and the release.
If a project is preparing for a release - it should be sure that it have
stable components to use ( even if he's not involved in writing the
components ).
Those are different items. I have no intention to participate in a
"closed" library ( neither as writer nor reader ).
I think (2) would do a lot in encouraging projects to use the library, but
it's not that important for me ( well, as a tomcat commiter I would -1
using a component that may change in the middle of a release without any
way to control that from tomcat side - but other projects may want to take
the risk ).
> * This could result in a groady mess - if any 'regular Jakarta project'
> can at any time for any reason start another 'library sub-project', then
> there is *nothing* that compels people to work together.
Any regular jakarta project can create code that is reusable - the library
commiters don't have any monopoly on reusable code.
And if a projects wants to share this code - I think the library is the
right place, and the library commiters don't have a monopoly on "the right
way to do a component" - only users can decide if they want to use a piece
of code or not.
> * This last suggestion promotes a project using a component from the
> role of user to a 'default committer status' with veto power, without
> any required investment in the project itself ?
Yes - that's exactly what I'm sugesting. I don't think any project will (
or should ) use a component if it doesn't have at least some control over
the component.
> * This dilutes the potential for 'productizing' some of the things
> present here in Jakarta into packaged, usable compoenents, since nothing
> prevents 7 connection pools from being in existance.... I fear
> duplication of effort again...
Nothing should prevent 7 connection pools.
If you want to prevent duplication you should make sure that every project
feels it's better ( for the project goals ) to use the existing connection
pool instead of writing another one.
Costin
