On 3/2/06, Simon Kitching <[EMAIL PROTECTED]> wrote: <snip/> > > We should probably be more careful about what projects are accepted into > commons. <snap/>
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. <snip/> 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. > <snap/> 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. -Rahul > Cheers, > > Simon > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
