On Tue, Feb 15, 2011 at 1:33 PM, Mark Miller <markrmil...@gmail.com> wrote: >> >> It appears to me, that the effort to commit the contributions are minimal, >> and that in this case the true cost is that of doing the release. > > Heh. I think looks can be deceiving sometimes. I'm not sure I'm willing to > hold the responsibility of those commits right now. If someone else is, > that's great ... but I don't find them minimal enough for my taste I suppose > ;) Depends on what areas you feel comfortable with I guess. >
Right, this is why some features with functional patches are sitting targeted at 3.2 instead of 3.1. Is it possible that we could put distributed date faceting (SOLR-1709), better cjk handling out of box (LUCENE-2906), and a better default merge policy (LUCENE-854) all in 3.1 right now? sure it is. But is this the best decision... I don't think it is. I think as far as 3.1 goes we already have a great set of features that have baked for some time, including some rather serious performance improvements (Mike and I have done some benchmarking against 3.0)... and its already going to be a more challenging release since its the first one since we merged lucene and solr. For these newer features, its not that we are lazy... its that sometimes you want more tests, want things to "bake" for a while with hudson's random testing, perhaps want some reviews/second pairs of eyes on the code, or maybe even just some more time to think about the change before committing to it. When we commit it and release it, we are signing up for some degree of support in the future. Also, personally I think its better to put out a good release with solid code and a few less features, than a more buggy release that has a couple of extra features. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
