db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [RFC] Draft DB Commons Proposal
Date Thu, 20 Feb 2003 20:03:50 GMT

I'm +1 on the concepts of incubation and commons being separate.

My view of Jakarta Commons is that the Jakarta Commons Sandbox really
should be renamed to Jakarta Sandbox as it's lead to Commons projects
which do not fit in

On 20 Feb 2003, John McNally wrote:

> Can there be any objective criteria to determine whether a project is
> more appropriate as a subproject of db instead of a subproject of
> db-commons? If jakarta-commons-dbcp proposes itself as a db-commons
> component and is approved.  Then later poolman proposes itself as a
> subproject of db, would it be appropriate to -1 based on the fact that
> db-commons has declared connection pools as appropriate to its scope and
> so poolman should submit itself as a component in db-commons?

This makes sense. The existence of other sub=projects in Turbine and
Avalon have partly lead to this being more of an issue, I'm not sure
Jakarta has had experience of a 'top level' Jakarta project clashing with

> My experience with jakarta-commons is mostly positive, but the lack of
> scope has troubled me.  The size of the codebase would seem to be an
> indicator of the amount of developer resources it will consume and the
> amount of mailing list traffic it will generate (at least dev, maybe not
> user).  I think some jakarta-commons components should be full
> subprojects of jakarta.

My worry has been the lack of view on the concept of a Commons-developer.
The idea in the charter is that there is no such thing as a Commons-dev,
instead other proejcts merely use Commons as a place to share.

In reality Commons has its own small community[ies], and projects which
have grown inside Commons.

> Could we have the sandbox concept as a separate entity from db-commons?
> Once a project that started in the sandbox is ready for release, it
> could either propose itself to either the db pmc or directly to the
> commons committers.  It would make the decision on where to end up more
> a function of the state of the code/community when a release is
> upcoming.  The default path in jakarta is from sandbox to commons proper
> and since that is the easiest path, I think it is often chosen for
> convenience.

I think it happens out of the poor definition of jakarta-commons-sandbox.
It's thought of as a place to incubate commons projects.


View raw message