On Sep 22, 2008, at 11:37 AM, Jason Rutherglen wrote:
where we have a "stable" and an "experimental"
release.
Good idea. Also may be good to nominate a release manager. It seemed
like features were being thrown in constantly that were perhaps beyond
the intended scope (was there one?) of SOLR 1.3. Probably next time,
maybe 2-3 large features and some bug fixes and then do a release.
I only have two data points on this that I can add. On the Lucene
Java side, it's always been a bit like herding cats. It really is up
to the community, and usually a few committers to push for a release.
We have a tacit agreement that we would like to release every 4-6
months. If you look at the Solr archives, we would often saw people
asking when is 1.3 going to be out and our response was usually
something like "we're working on X", and X kept changing. This isn't
a bad thing, necessarily. Open Source is hard to plan, you never know
where some nice new idea is coming from, so it could be there is
momentum towards a release and then bam, someone comes in w/ a big new
bug or a big feature. Still, we could be better about saying, OK,
this is great, let's do a release in 2 weeks and then add this nice
new feature.
On the flip side of my experience is Hadoop. Y! has assigned a number
of resources to it, a number of which are committers, and also others
as support. They have people providing management in JIRA, driving
release planning, etc. Subscribing to the dev list is darn near
overwhelming. They also have fairly well timed out releases w/ well
enumerated list of features, fixes, etc. In other words, it's more
commercially driven.
Personally, I think we just need to have some sort of "verbal"
agreement, as committers/contributors to work towards more timely,
smaller releases. I don't want to release just for the sake of
releasing, but I also want to see incremental advancements available
to more people more often.
-Grant
