commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [feedparser] News / Status
Date Thu, 02 Mar 2006 23:02:53 GMT
On 3/2/06, Simon Kitching <> wrote:
> We should probably be more careful about what projects are accepted into
> commons.

Agreed, but how do we do that?

On one hand, its too easy to start a project in Commons, and then have
the project stall (for a plethora of reasons). OTOH, our charter says
the sandbox is fairly "open". Needs some objective definition if we're
going to be selective (such as saying something to the effect of your
sentence below and then standing firm).

> Existing successful code factored out of another project
> because people want to use it in multiple projects -- fine. That's the
> original basis for commons.

Precisely why [scxml] came to be in Commons.

> Brand new code with small developer
> communities could perhaps be better developed elsewhere but using the
> Apache license so it can become a commons component later if desirable.
> The real problem to me is where a popular commons component becomes more
> "stable" and thus community dwindles to the point where there aren't
> enough votes to continue maintenance releases. Logging is marginal as is
> Digester; lots of users but not many developers.

May well be the case, but for the two specific examples you take up:

 * IMO, the recent vote for [logging] is not a good example. It
appears there was confusion about the alpha labeling. I think most of
us use JCL one way or the other, that single vote may not be a good
indication of developer/voter/community support.

 * I'd also like to think that Digester can make a maintenance release
the next time it comes up. I use it, and I know many others here use
it too.

Anyway, at this point, we're probably far OT to this thread.


> Cheers,
> Simon

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message