db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [RFC] Draft DB Commons Proposal
Date Mon, 24 Feb 2003 14:48:55 GMT
On Thu, 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?

> 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.

I think we may find it difficult to define objective criteria to that
effect.  Size metrics are probably a strong indicator, but not a
sufficient one.  For instance, the (currently sandboxed) commons-functor
component in jakarta-commons currently has over 100 classes and roughly
4000 non-comment, non-blank lines of code.  That may grow another 50% or
more before it's proposed as for commons proper.  Cactus is about the same
size, maybe even a little smaller (73 classes and roughly 4000 lines of
code according to the clover report) but is a jakarta subproject.  To me
the placement of each is appropriate, and is in part a function of the
complexity, specialization and appliciablity of the individual "project".

> 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?

Personally, I think a database connection pool is about the right size for
a commons component, and a little too small for a top-level subproject
(and perhaps a lot too small at this time for a top- (i.e., apache-) level
project).  I'd encourage both poolman and dbcp, if either is to move to
db-apache, to place themselves within db-commons, as I believe that both
would thrive there best.

That said, I don't think I'd vote -1 on poolman as a subproject of db (as
opposed to a component of db-commons), but I do think I'd support someone
else's right to do so (remember, it's a majority, not a consensus vote, so
there is no strict veto).  I believe that pool-as-component would be
beneficial for that codebase, and that pool-as-project may be
deterimental, but I think Sam's notion of "what the committers are willing
to commit to" is the overriding principle here.

One thing to keep in mind in this scenario is that a component of
db-commons could at any time purpose itself for promotion(*) to a
sub-project of the db project, or as a top-level ASF project, as cactus
has done in jakarta-commons, and as httpclient and jelly probably should.

(*) - I think "promotion" is the wrong word here, but I can't think of
anything better.  I'd encourage everyone to see the spectrum of
apache-top-level, sub-project, or sub-project-component less as
gradations of status and more as administrative details.  I.e.,
determine which community model fits best, not how "important" you
believe the code base to be.

> 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.

Other than the name "db-commons-sandbox", there's not a lot db-commons
specific about the sandbox, in particular it is open to any db committer.

It probably makes sense for someone to be responsible for the contents of
the sandbox.  As proposed (and as it works in jakarta-commons), this would
be the db-commons committers.  The DB PMC is the only other option that
makes sense to me (short of adding a db-incubator type of project).  I'm
currently on both lists, so either way doesn't have much impact on me (or,
more accurately, either way has the same impact on me), so I'm having
trouble coming up with a strong opinion on the matter.

The general point of "sometimes it may be more appropriate for a component
to move from the sandbox to a standalone sub-project" is one I would agree
with.  Perhaps it's simply a matter of making this option clear and
accessible to [sandbox] component developers.


Mime
View raw message