Not to simplify what could be a much more complicated response, but: If you have an issue you really want to get into 3.1, especially if you are willing to work on it, your best bet was/is probably to jump into JIRA and lobby for that issue. Action, more than anything, drives these things around here IMO. If any given issue does not make the cut, I'm not too personally worried though. There is a lot of goodness to release. Releases don't happen enough. Either effort will come forth and deliver things to the 3.1 release (seems a bit late now but...) - or we should just let them role to the next release I think. Lucene/Solr have always been much more scratch your itch than centrally plan.
Releases have also been pretty infrequent around here - best bet is usually to help them just role along - and start piping in work in the directions you want to guide things as you see fit. It takes long enough to release generally even with that mentality :) This release is getting ready to leave the station though - IMO, best move is to help push it out the door (I wish I could have helped more already) rather than fret about what could be added to it. - Mark On Feb 12, 2011, at 7:38 PM, David Smiley (@MITRE.org) wrote: > > I don't want to overstep my role in this conversation (not being a committer > as much as I want to be), but shouldn't there be some thought about what we > should *add* to 3.x before 3.x gets rushed out the door? I have no doubt 3.x > will be stable; I didn't mean "rushed" in that sense. I'm sure we have in > our minds an issue or two that for whatever reason hasn't been committed but > should be. Well I take that back, I'm talking to the wrong group of folks > since you all would have committed it then! ;-) > > One that comes to mind (and to several others I know) is SOLR-1709 > Distributed date faceting. This has had working code for a long time, though > admittedly not a proper patch nor tests. That issue sorely needs to get > committed IMO. And then, it may not qualify as a "bug", but a release is an > opportunity to tidy up the /browse interface. I tried to use it recently in > 3x and it felt half-baked. FWIW, this is a competitive advantage that > Endeca has over Solr -- they have a default browser that is quite good and > its indispensable. > > I'm tempted to also bring up my distaste for the next version of Solr being > 3.something instead of 1.5 (in fact I just did) but I'll just leave it at > that. AFAIK that battle was lost months ago. > > ~ David Smiley > > > Robert Muir wrote: >> >> ... >> Despite this, I propose we do a 'casual freeze' on the 3.x code base >> in 7 days time, in other words we agree for a few weeks we will focus >> on bugs and tests only in branch_3x and try to shorten, not length the >> list of issues in JIRA (unless these issues are bugs!). >> >> The reason I say this, versus creating a release branch right now, is >> that I think we should take advantage of our stable branch (branch_3x) >> and avoid branching until the last minute: when we are ready to make >> an RC. >> >> I think any features/improvements that cannot be done in 7 days should >> really wait for 3.2 instead... and we shouldn't wait a year for that >> one to release either... we have a stable branch, lets take advantage >> of it. >> ... >> > > > ----- > Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book > -- > View this message in context: > http://lucene.472066.n3.nabble.com/wind-down-for-3-1-tp2414923p2483224.html > Sent from the Solr - Dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - Mark Miller lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
