On Thu, 2006-03-02 at 17:50 -0500, Rahul Akolkar wrote: > On 3/2/06, James Carman <[EMAIL PROTECTED]> wrote: > > I would have to agree that the release process is a bit daunting. That's > > why I haven't released Commons Proxy 1.0 yet. I really don't know how to do > > all of that stuff on the release preparation document (md5 signatures and > > the like). > > > <snip/> > > Is that really the only reason? With [proxy] (and [scxml] as well), > one of the glaring reasons I see is that they're still in sandbox. We > *couldn't* release them right now, irrespective of how daunting the > task of cutting a release may be. I'd say, its different.
What you can't do is have binaries built from sandbox code then distributed from the official Apache mirrors. And that seems right to me; distribution from the official site(s) implies that the project has passed Apache's tests for quality -- including having a community of developers trusted by Apache to verify and maintain it. The fact that the code is still in the sandbox implies that the project has NOT passed those tests. It doesn't mean the code isn't good; it may be brilliant. However if there isn't a community of existing apache committers looking at the code, Apache doesn't *know* it's brilliant. I believe that binaries can still be built from sandbox code and distributed from your people.apache.org address, and that the sandbox site can point to that location as a source of "unofficial" binaries. If SCXML is factored out of an existing project, then can't you get half-a-dozen committers from that project to put themselves forward as commons committers then call for the promotion of SCXML followed by a release? Approval of existing committers from another Apache project won't take long, as long as they really are serious about verifying and maintaing SCXML. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
