Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-31 Thread Simon Willnauer
sorry guys I won't have time to look at this candiates due to buzzwords. Thanks for all the work. simon On Mon, May 30, 2011 at 7:01 PM, Grant Ingersoll gsing...@apache.org wrote: On May 28, 2011, at 6:10 PM, Robert Muir wrote: On Sat, May 28, 2011 at 5:09 PM, Grant Ingersoll

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Shai Erera
+1. I did not find any issues besides those Mark and Robert reported. If you respin, will it be done from the latest 3x revision? If so, it means a couple more issues will be released as well, in which case we need to ensure their Fix Version is still 3.2. Also, there are issues that are marked

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Doron Cohen
Hi, I am in favor of not waiting for last minute changes and think we should release this RC if it has no major problems. Here is what I have: 1) In lucene tar-gz format is file.tar.gz while in solr it is file.tgz. Not a blocker but I think we would like them to be the same in the future? 2)

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Bill Bell
Let's move it! From: Shai Erera ser...@gmail.com Reply-To: dev@lucene.apache.org Date: Mon, 30 May 2011 12:15:58 +0300 To: dev@lucene.apache.org Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 +1. I did not find any issues besides those Mark and Robert reported. If you respin

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Robert Muir
On Mon, May 30, 2011 at 5:15 AM, Shai Erera ser...@gmail.com wrote: +1. I did not find any issues besides those Mark and Robert reported. If you respin, will it be done from the latest 3x revision? If so, it means a couple more issues will be released as well, in which case we need to ensure

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Shai Erera
I wasn't trying to shove last minute changes into the release, just asked a technical question. I didn't realize we already have a branch for 3.2, I thought we were going to only tag 3.2.0. But maybe branching is not a bad idea - we branch before a release, fix an RC issues on the branch and then

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Mark Miller
On May 30, 2011, at 3:52 PM, Robert Muir wrote: In all cases it would be good to see if we can fix the problem in some way so that it doesn't pop up in a future release... for example the solrconfig.xml version was not bumped, we could at a minimum add it to the wiki page so it isn't

RE: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Steven A Rowe
/*/CHANGES.txt have 3.2-dev as the release header. -1 to RC1 based on this. Steve -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Friday, May 27, 2011 11:50 AM To: dev@lucene.apache.org Dev Subject: [VOTE] Release Lucene/Solr 3.2.0 Please vote to release

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Robert Muir
On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe sar...@syr.edu wrote: First, I want to say that I think being able to release more frequently is great.  Thanks Mike for taking the initiative. But we need to be able to fix packaging problems, and the only time we look at them is at release

RE: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Steven A Rowe
On 5/30/2011 at 5:16 AM, Shai Erera wrote: LUCENE-3004 is marked a blocker for 3.2 - are we going to move it to 3.3 or hold up 3.2? +1 to move LUCENE-3004 to 3.3. On 5/30/2011 at 3:53 PM, Robert Muir wrote: As much as I love LUCENE-3147, I'm not sure if we should try to shove code changes

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Robert Muir
On Mon, May 30, 2011 at 4:25 PM, Steven A Rowe sar...@syr.edu wrote: On 5/30/2011 at 5:16 AM, Shai Erera wrote: LUCENE-3004 is marked a blocker for 3.2 - are we going to move it to 3.3 or hold up 3.2? +1 to move LUCENE-3004 to 3.3. I am -1 to this. LUCENE-3004 is a vague (but good) idea to

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Upayavira
Watching the various wishes on this thread (release early, release often; I want feature X included in the release; etc), I'd propose this for an approach that I believe could cover all bases: * Anyone can propose a release * They should give n days warning (suggest 1 wk) * Ideally, a code

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Robert Muir
On Mon, May 30, 2011 at 4:25 PM, Steven A Rowe sar...@syr.edu wrote: Here is my proposal: let's open a JIRA issue for each thing that was found, and we decide which are blockers and we backport those to the branch. The rest we should try to fix in 3.3 +1 OK, I tried to open a jira issue

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Robert Muir
On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe sar...@syr.edu wrote: 2. All contrib/*/CHANGES.txt have 3.2-dev as the release header.  -1 to RC1 based on this. Just curious why you vote -1 to this in 3.2, when it was broken in this same way in 3.1 :) Seriously, this is enough to block a

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Otis Gospodnetic
Message From: Upayavira u...@odoko.co.uk To: dev@lucene.apache.org Sent: Mon, May 30, 2011 5:10:54 PM Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 Watching the various wishes on this thread (release early, release often; I want feature X included in the release; etc), I'd propose

RE: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Steven A Rowe
@lucene.apache.org Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe sar...@syr.edu wrote: 2. All contrib/*/CHANGES.txt have 3.2-dev as the release header.  -1 to RC1 based on this. Just curious why you vote -1 to this in 3.2, when it was broken

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Robert Muir
On Mon, May 30, 2011 at 9:20 PM, Steven A Rowe sar...@syr.edu wrote: Yeah, I think it's enough to block a release: broken windows syndrome. It sucks that it was wrong in the 3.1 release - if I'd noticed it then, I would have -1'd it then. its not really broken windows syndrome, there are a

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-30 Thread Mark Miller
Let's not get caught up too much in the details of a -1 on release, unless it garners a heavy choir behind it. We want to address any issues that make sense to address, of course. But the person rolling the release gets to make the call on what is in the release, as well as whether or not to

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-29 Thread David Smiley (@MITRE.org)
You're right; it shouldn't be shoved in at the last second -- I didn't mean to imply that. It should be committed and then we'll give it a comfortable amount of time. When that time is up, and if v3.2 waits for it, then 3.2 will probably be at about the 3-month mark since the last release -- in

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-29 Thread Robert Muir
On Sun, May 29, 2011 at 2:14 AM, David Smiley (@MITRE.org) dsmi...@mitre.org wrote: Releasing too fast / too infrequent aside, I think a X.X release should have a notable feature (or a huge performance improvement), and 3.2 doesn't without result grouping, IMO. It's got plumbing and bug fixes.

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-29 Thread Simon Willnauer
Hi David, On Sat, May 28, 2011 at 11:14 PM, David Smiley (@MITRE.org) dsmi...@mitre.org wrote: You're right; it shouldn't be shoved in at the last second -- I didn't mean to imply that. It should be committed and then we'll give it a comfortable amount of time.  When that time is up, and if

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-29 Thread Robert Muir
On Sun, May 29, 2011 at 3:27 AM, Simon Willnauer simon.willna...@googlemail.com wrote: and we the lucene PMC agreed on the fact that a release doesn't need to have large features. We simply don't want to let folks wait for years anymore. I think its a lot more than this really... I think we

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Michael McCandless
+1, we shouldn't swing the pendulum too far in the other direction. Everything in moderation... even moderation ;) One small correction below: result grouping isn't in Solr 3.2 (the grouping module will be in 3.2)... hopefully 3.3 ;) Mike http://blog.mikemccandless.com On Sat, May 28, 2011 at

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Robert Muir
On Sat, May 28, 2011 at 8:37 AM, Michael McCandless luc...@mikemccandless.com wrote: +1, we shouldn't swing the pendulum too far in the other direction. Are we talking about the same open source project? the *last* thing we should be worrying about right now is releasing too much!

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread johnmunir
-Original Message- From: Robert Muir rcm...@gmail.com To: dev@lucene.apache.org Sent: Sat, May 28, 2011 8:40 am Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 On Sat, May 28, 2011 at 8:37 AM, Michael McCandless luc...@mikemccandless.com wrote: +1, we shouldn't swing the pendulum too far

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Mark Miller
To: dev@lucene.apache.org Sent: Sat, May 28, 2011 8:40 am Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 On Sat, May 28, 2011 at 8:37 AM, Michael McCandless luc...@mikemccandless.com wrote: +1, we shouldn't swing the pendulum too far in the other direction. Are we talking about the same open

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread David Smiley (@MITRE.org)
The basis of my preference to start the 3.2 release was the existence of some cool meaningful feature in it over the previous release. Since Result Grouping isn't going to make it, I am not in favor of releasing 3.2. Why not wait till we're happy with it being committed? I've toyed with it a

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Mark Miller
The cost of the overhead is paid by volunteers - there is no *need* to release every month. But if someone is so concerned that a few features have not made it in this release that are important - there is no reason not too as well - given that the person is willing to roll the release.

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Mark Miller
Doesn't it seem like result grouping should have a bit of time in svn, getting some early testing, getting exposed to random testing, rather than shoving it in last second into a release? The reason I'm not worried that people didn't have a window to shove stuff in at the end, is that I don't

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Grant Ingersoll
I think I kicked off the 3.2 release discussion back a bit saying it's been about 3 mos (come June). To me, roughly every 3 months or so is ideal. I'm thinking about setting up a Google calendar that we can put reminders on (as well as other Lucene related events) and then share it publicly

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Robert Muir
On Sat, May 28, 2011 at 5:09 PM, Grant Ingersoll gsing...@apache.org wrote: I think I kicked off the 3.2 release discussion back a bit saying it's been about 3 mos (come June).  To me, roughly every 3 months or so is ideal. I'm thinking about setting up a Google calendar that we can put

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread Bill Bell
I would suggest that we put in Result Grouping SOLR-2524 in 3.2... I agree that is seems like we have all waited long enough for that feature. On 5/27/11 11:25 PM, David Smiley (@MITRE.org) dsmi...@mitre.org wrote: Clearly a year+ is too long to release, and thankfully it appears that's in the

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-28 Thread David Smiley (@MITRE.org)
Cool idea! I had the same thought -- an automated reminder every 2.5 months or so. - Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2997954.html Sent from

[VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Michael McCandless
Please vote to release the artifacts at: http://people.apache.org/~mikemccand/lucene_solr_320/rc1/ as Lucene 3.2.0 and Solr 3.2.0. Mike http://blog.mikemccandless.com - To unsubscribe, e-mail:

RE: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Dyer, James
Group (615) 213-4311 -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Friday, May 27, 2011 10:50 AM To: dev@lucene.apache.org Dev Subject: [VOTE] Release Lucene/Solr 3.2.0 Please vote to release the artifacts at: http://people.apache.org/~mikemccand

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Shai Erera
Systems Ingram Content Group (615) 213-4311 -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Friday, May 27, 2011 10:50 AM To: dev@lucene.apache.org Dev Subject: [VOTE] Release Lucene/Solr 3.2.0 Please vote to release the artifacts at: http

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Robert Muir
+1 i found a 'foo.txt' in the root of lucene-3.2.0.zip with the text 'kajdsfkj' in it, but I don't think this need to block anything. On Fri, May 27, 2011 at 8:50 AM, Michael McCandless luc...@mikemccandless.com wrote: Please vote to release the artifacts at:  

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Robert Muir
On Fri, May 27, 2011 at 9:57 AM, Shai Erera ser...@gmail.com wrote: from releasing. However, by following a certain protocol about a release, we give people enough time to prepare for it. I am confused why we need to have a protocol where people have time to plan? Isn't it true that what we

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Shai Erera
I am confused why we need to have a protocol where people have time to plan? Why not :)? Are protocols bad? From my experience, protocols only help clarify things. And it's not a 100 pages protocol -- the one that you've followed (even though not written one) makes sense to me. But then, we

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Robert Muir
True. Only thought that we might want to give people time to ensure that things that are important to them are included in 3.2. Why? if these issues are so critical they should be marked as blockers! Again, why wait a week, we could release again in a week instead! This whole lifecycle is

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Simon Willnauer
I think robert is right here. We want to do more frequent releases and to go that path we need to stop waiting for a week for feature / improvement X. We can spin another release in 4 weeks I think we should actually. If we do that and increment the version number by 1 each time we reach 3.9 by

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Michael McCandless
On Fri, May 27, 2011 at 1:18 PM, Shai Erera ser...@gmail.com wrote: Only thought that we might want to give people time to ensure that things that are important to them are included in 3.2. I know this approach is tempting, and what we normally do, but I think this is the core problem of why

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Shai Erera
Ok let's give it a try. I'll test the artifacts by Sunday. Shai On Fri, May 27, 2011 at 8:43 PM, Michael McCandless luc...@mikemccandless.com wrote: On Fri, May 27, 2011 at 1:18 PM, Shai Erera ser...@gmail.com wrote: Only thought that we might want to give people time to ensure that

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Bill Bell
release should include a fix for this. James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Friday, May 27, 2011 10:50 AM To: dev@lucene.apache.org Dev Subject: [VOTE] Release Lucene/Solr 3.2.0

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread Mark Miller
Won't have time to test the artifacts today, but my opinion (even though it sounds settled): If someone really wants a few features in, lets release 3.3 next month :) Otherwise, lets just start releasing - that's the whole point of the make it easier to release push. People shouldn't need to

Re: [VOTE] Release Lucene/Solr 3.2.0

2011-05-27 Thread David Smiley (@MITRE.org)
Clearly a year+ is too long to release, and thankfully it appears that's in the past for Lucene/Solr. But on the other extreme, one can release too quickly as well, of course. There is overhead to performing the release itself. Consequently there should be enough goodness in the release to make