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

---------------------------------------------------------------------

Michael,

A while ago I submitted SOLR-2462 with a patch to fix a critical bug in Solr's spellchecker.  I'm not sure if the patch included is the best approach to fixing the problem but I do think any next release should include a fix for this.

James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-----Original Message-----
From: Michael McCandless [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 27, 2011 10:50 AM
To: [EMAIL PROTECTED] Dev
Subject: [VOTE] Release Lucene/Solr 3.2.0

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

---------------------------------------------------------------------
---------------------------------------------------------------------

Mike

Thanks for taking the initiative !

Do you think we can allow for 1 week or so in order for people to be able to
finish things they're currently working on (and expect to finish within the
next few days) and want them to be in 3.2?

I ask because I don't recall seeing a "feature freeze" note, or candidate
date or anything on 3.2. I know I can use 2-3 more days to finish few issues
(such as LUCENE-3147, which fixes numerous leaked file handles).

With 3.1, IIRC, we gave a 1 month notice about the candidate release date.
Then we allowed 1 week for people to sort out their issues and move to 3.2
any they didn't think they'll make it on time. After that week, we moved all
unassigned ones to 3.2. That's kind of the process I was expecting w/ 3.2
... if this notice has been given (and I missed it), then I apologize and
will test the artifacts you published.

Don't get me wrong, we will always have "more work" to do, and I don't think
we should let the number of open issues (currently for 3.2) hold us back
from releasing. However, by following a certain protocol about a release, we
give people enough time to prepare for it.

Shai

On Fri, May 27, 2011 at 7:27 PM, Dyer, James <[EMAIL PROTECTED]>wrote:

> Michael,
>
> A while ago I submitted SOLR-2462 with a patch to fix a critical bug in
> Solr's spellchecker.  I'm not sure if the patch included is the best
> approach to fixing the problem but I do think any next release should
> include a fix for this.
>
> James Dyer
> E-Commerce Systems
> Ingram Content Group
> (615) 213-4311
>
>
> -----Original Message-----
> From: Michael McCandless [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 27, 2011 10:50 AM
> To: [EMAIL PROTECTED] Dev
> Subject: [VOTE] Release Lucene/Solr 3.2.0
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

+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
<[EMAIL PROTECTED]> wrote:
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Fri, May 27, 2011 at 9:57 AM, Shai Erera <[EMAIL PROTECTED]> 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 have now in 3.2 is better than 3.1?  So why
would you be against releasing it, if its better?

Any issues can be fixed in 3.3, we could do this a week later if we wanted.

---------------------------------------------------------------------

>
> 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
didn't make it to the target date eventually ...
> So why would you be against releasing it, if its better?
I'm not against releasing, just was taken by surprise and intended to have a
few more issues in 3.2. I didn't vote -1, just asked if Mike will be willing
to allow for 1 more week.

Isn't it true that what we have now in 3.2 is better than 3.1?
True

Any issues can be fixed in 3.3, we could do this a week later if we wanted.
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.

But I don't want to hold off that release. Surely Mike has taken a great
step towards "releasing more often", so I'm willing to give that process a
try :).

Shai
> On Fri, May 27, 2011 at 8:03 PM, Robert Muir <[EMAIL PROTECTED]> wrote:

> On Fri, May 27, 2011 at 9:57 AM, Shai Erera <[EMAIL PROTECTED]> 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 have now in 3.2 is better than 3.1?  So why
> would you be against releasing it, if its better?
>
> Any issues can be fixed in 3.3, we could do this a week later if we wanted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

>
> 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 broken:
1. hey everyone, lets release in X days.
2. people rush in all their favorite pet features, maybe in sloppy
fashion since they really want to get them in, which destabilizes the
code.
3. we generate RC after RC because in each one someone finds a new
bug... there are always bugs and if 3.2 doesnt introduce the bug, i
dont think it should block it... 3.2 fixes some bugs and we can fix
more bugs in 3.3

---------------------------------------------------------------------

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 the end of the year, just ready for 4.0 :)

here is my +1

On Fri, May 27, 2011 at 10:23 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
>>
>> 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 broken:
> 1. hey everyone, lets release in X days.
> 2. people rush in all their favorite pet features, maybe in sloppy
> fashion since they really want to get them in, which destabilizes the
> code.
> 3. we generate RC after RC because in each one someone finds a new
> bug... there are always bugs and if 3.2 doesnt introduce the bug, i
> dont think it should block it... 3.2 fixes some bugs and we can fix
> more bugs in 3.3
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Fri, May 27, 2011 at 1:18 PM, Shai Erera <[EMAIL PROTECTED]> 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 our releases drag out so long.

I think we should in fact do the reverse: simply "release" frequently
off of our stable branch, whatever point it's at, without waiting for
anything except blockers.  This is the huge benefit of having a
separate stable branch ("always releasable"), and we have yet to tap
that.

I too have things I want to commit (eg, the single-pass grouping
collector, maybe nested docs soon, etc.), but these can just as well
wait for 3.3.

If we know we will have frequent releases going forward then suddenly
it's much less important to squeeze stuff in to a given release; just
catch the next one.  It's sort of chicken-and-egg :)

+1 to release.

Mike

http://blog.mikemccandless.com

---------------------------------------------------------------------

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 <
[EMAIL PROTECTED]> wrote:

> On Fri, May 27, 2011 at 1:18 PM, Shai Erera <[EMAIL PROTECTED]> 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 our releases drag out so long.
>
> I think we should in fact do the reverse: simply "release" frequently
> off of our stable branch, whatever point it's at, without waiting for
> anything except blockers.  This is the huge benefit of having a
> separate stable branch ("always releasable"), and we have yet to tap
> that.
>
> I too have things I want to commit (eg, the single-pass grouping
> collector, maybe nested docs soon, etc.), but these can just as well
> wait for 3.3.
>
> If we know we will have frequent releases going forward then suddenly
> it's much less important to squeeze stuff in to a given release; just
> catch the next one.  It's sort of chicken-and-egg :)
>
> +1 to release.
>
> Mike
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

+1 (if I get a vote)

On 5/27/11 10:27 AM, "Dyer, James" <[EMAIL PROTECTED]> wrote:

>Michael,
>
>A while ago I submitted SOLR-2462 with a patch to fix a critical bug in
>Solr's spellchecker.  I'm not sure if the patch included is the best
>approach to fixing the problem but I do think any next release should
>include a fix for this.
>
>James Dyer
>E-Commerce Systems
>Ingram Content Group
>(615) 213-4311
>
>
>-----Original Message-----
>From: Michael McCandless [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 27, 2011 10:50 AM
>To: [EMAIL PROTECTED] Dev
>Subject: [VOTE] Release Lucene/Solr 3.2.0
>
>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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

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 worry about cramming something in last minute (which doesn't seem good anyway) - just jump on the next soon to release release.

- Mark
---------------------------------------------------------------------

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 it feel worthwhile. And because we value stability and robustness in
Lucene/Solr, changed code should have *some* amount of time to be
potentially used and tested further.  And there's impact on the user
community. If a release occurred too frequently then there might be very
little meaningful improvements in the release. I believe it is Hudson (now
Jenkins) that followed that extreme of I think releasing every week or so.
It's so frequent that as an admin of such a server where I work, I don't
even care to look at what's new in the releases because there are too many
of them--I've become apathetic when I was initially excited to use it. So
hopefully with each release there's something truly cool to tell others
about in Lucene/Solr.  

Gauging these factors is of course very subjective.  Personally, I think 3
months is just right, 1 or less is too fast. Given that v3.1 was released 2
months ago and there are some truly cool features like Result Grouping in
Solr to announce in 3.2. I'm in favor of a release.

~ David Smiley

-----
 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-tp2993434p2995419.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

---------------------------------------------------------------------

+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 1:25 AM, David Smiley (@MITRE.org)
<[EMAIL PROTECTED]> wrote:
> 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 it feel worthwhile. And because we value stability and robustness in
> Lucene/Solr, changed code should have *some* amount of time to be
> potentially used and tested further.  And there's impact on the user
> community. If a release occurred too frequently then there might be very
> little meaningful improvements in the release. I believe it is Hudson (now
> Jenkins) that followed that extreme of I think releasing every week or so.
> It's so frequent that as an admin of such a server where I work, I don't
> even care to look at what's new in the releases because there are too many
> of them--I've become apathetic when I was initially excited to use it. So
> hopefully with each release there's something truly cool to tell others
> about in Lucene/Solr.
>
> Gauging these factors is of course very subjective.  Personally, I think 3
> months is just right, 1 or less is too fast. Given that v3.1 was released 2
> months ago and there are some truly cool features like Result Grouping in
> Solr to announce in 3.2. I'm in favor of a release.
>
> ~ David Smiley
>
> -----
>  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-tp2993434p2995419.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Sat, May 28, 2011 at 8:37 AM, Michael McCandless
<[EMAIL PROTECTED]> 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!

---------------------------------------------------------------------

Too many releases maybe a bad idea, not only will there be too many questions to users such as what version are you using, have you tried version X, the latest, etc. but you may lose your trust with some of the more serious organizations who see stability ahead of frequent releases.
-JM

-----Original Message-----
From: Robert Muir <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]> 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
hould be worrying about right now is releasing too much!
---------------------------------------------------------------------
o unsubscribe, e-mail: [EMAIL PROTECTED]
or additional commands, e-mail: [EMAIL PROTECTED]

This is why we have a stable branch and a 4X branch. There are *many* projects that have mastered releasing frequently - we could easily be one of them.

Sent from my iPad

On May 28, 2011, at 9:14 AM, [EMAIL PROTECTED] wrote:

> Too many releases maybe a bad idea, not only will there be too many questions to users such as what version are you using, have you tried version X, the latest, etc. but you may lose your trust with some of the more serious organizations who see stability ahead of frequent releases.
> -JM
>
>
> -----Original Message-----
> From: Robert Muir <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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
> <[EMAIL PROTECTED]> 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!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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 week
ago and was pleased.

Here are the list of LUCENE and SOLR JIRA issues of type improvement or
new-feature with a resolution of fixed with a priority greater than "minor"
and a fix-version for 3.2:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+issuetype+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%223.2%22+and+priority+%3E+minor
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+issuetype+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%223.2%22+and+priority+%3E+minor

~ David Smiley

-----
 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-tp2993434p2996144.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

---------------------------------------------------------------------

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.

Releases take 3 +1s - I'll give my +1 as often as someone puts artifacts in front of me and I have time to verify them.

The worry of releasing TOO much is so premature it's not even funny :)

Sent from my iPad

On May 28, 2011, at 1:25 AM, "David Smiley (@MITRE.org)" <[EMAIL PROTECTED]> wrote:

> 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 it feel worthwhile. And because we value stability and robustness in
> Lucene/Solr, changed code should have *some* amount of time to be
> potentially used and tested further.  And there's impact on the user
> community. If a release occurred too frequently then there might be very
> little meaningful improvements in the release. I believe it is Hudson (now
> Jenkins) that followed that extreme of I think releasing every week or so.
> It's so frequent that as an admin of such a server where I work, I don't
> even care to look at what's new in the releases because there are too many
> of them--I've become apathetic when I was initially excited to use it. So
> hopefully with each release there's something truly cool to tell others
> about in Lucene/Solr.  
>
> Gauging these factors is of course very subjective.  Personally, I think 3
> months is just right, 1 or less is too fast. Given that v3.1 was released 2
> months ago and there are some truly cool features like Result Grouping in
> Solr to announce in 3.2. I'm in favor of a release.
>
> ~ David Smiley
>
> -----
> 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-tp2993434p2995419.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

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 think we should be shoving stuff in at the end. If a big feature was going to make this release, it should have been in and baking some time ago - otherwise, lets let it make to the next release. Shoving things in last minute is just not a good approach in my opinion.

- Mark

On May 28, 2011, at 9:48 AM, David Smiley (@MITRE.org) wrote:

> 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 week
> ago and was pleased.
>
> Here are the list of LUCENE and SOLR JIRA issues of type improvement or
> new-feature with a resolution of fixed with a priority greater than "minor"
> and a fix-version for 3.2:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+issuetype+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%223.2%22+and+priority+%3E+minor
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+issuetype+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%223.2%22+and+priority+%3E+minor
>
> ~ David Smiley
>
> -----
> 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-tp2993434p2996144.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

- Mark Miller
lucidimagination.com

Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
---------------------------------------------------------------------

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 (committers would have write access)
On May 28, 2011, at 9:49 AM, Mark Miller wrote:

> 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.
>
> Releases take 3 +1s - I'll give my +1 as often as someone puts artifacts in front of me and I have time to verify them.
>
> The worry of releasing TOO much is so premature it's not even funny :)
>
> Sent from my iPad
>
> On May 28, 2011, at 1:25 AM, "David Smiley (@MITRE.org)" <[EMAIL PROTECTED]> wrote:
>
>> 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 it feel worthwhile. And because we value stability and robustness in
>> Lucene/Solr, changed code should have *some* amount of time to be
>> potentially used and tested further.  And there's impact on the user
>> community. If a release occurred too frequently then there might be very
>> little meaningful improvements in the release. I believe it is Hudson (now
>> Jenkins) that followed that extreme of I think releasing every week or so.
>> It's so frequent that as an admin of such a server where I work, I don't
>> even care to look at what's new in the releases because there are too many
>> of them--I've become apathetic when I was initially excited to use it. So
>> hopefully with each release there's something truly cool to tell others
>> about in Lucene/Solr.  
>>
>> Gauging these factors is of course very subjective.  Personally, I think 3
>> months is just right, 1 or less is too fast. Given that v3.1 was released 2
>> months ago and there are some truly cool features like Result Grouping in
>> Solr to announce in 3.2. I'm in favor of a release.
>>
>> ~ David Smiley
>>
>> -----
>> 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-tp2993434p2995419.html
>> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--------------------------
Grant Ingersoll
---------------------------------------------------------------------

On Sat, May 28, 2011 at 5:09 PM, Grant Ingersoll <[EMAIL PROTECTED]> 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 reminders on (as well as other Lucene related events) and then share it publicly (committers would have write access)
>

then my first commit would be to change this to monthly or more often.

what are the technical reasons why we should not release this 3.2 candidate?

---------------------------------------------------------------------

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)" <[EMAIL PROTECTED]> wrote:

>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 it feel worthwhile. And because we value stability and robustness in
>Lucene/Solr, changed code should have *some* amount of time to be
>potentially used and tested further.  And there's impact on the user
>community. If a release occurred too frequently then there might be very
>little meaningful improvements in the release. I believe it is Hudson (now
>Jenkins) that followed that extreme of I think releasing every week or so.
>It's so frequent that as an admin of such a server where I work, I don't
>even care to look at what's new in the releases because there are too many
>of them--I've become apathetic when I was initially excited to use it. So
>hopefully with each release there's something truly cool to tell others
>about in Lucene/Solr.
>
>Gauging these factors is of course very subjective.  Personally, I think 3
>months is just right, 1 or less is too fast. Given that v3.1 was released
>2
>months ago and there are some truly cool features like Result Grouping in
>Solr to announce in 3.2. I'm in favor of a release.
>
>~ David Smiley
>
>-----
> 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-tp299343
>4p2995419.html
>Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

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 the Lucene - Java Developer mailing list archive at Nabble.com.

---------------------------------------------------------------------

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 my
view (and Grant's) the ideal suite-spot for a release window.

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.

~ David Smiley

-----
 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-tp2993434p2997968.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

---------------------------------------------------------------------

On Sun, May 29, 2011 at 2:14 AM, David Smiley (@MITRE.org)
<[EMAIL PROTECTED]> 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.
>

This is not true, it just doesn't have your pet feature, which isn't
any blocker for release. I don't see the issue marked as release
blocker

3.2 has:

* A new default merge policy that doesn't inadvertently optimize
* An index upgrade tool to allow users to upgrade indexes to the latest version
* Numeric fields finally "give you back" a NumericField
* A grouping module for lucene users
* A new NRTCachingDirectory
* Optimizations to highlighting performance

besides important bug fixes for the attributes API, stack overflows in
phrasequery, term dictionaries with more than 2 billion terms, and
other things.

This is a valuable set of changes for users and this is a volunteer
project, if we are volunteering to do the work to push out a 3.2
release, why does this bother you? the stuff you want can easily be in
3.3 in the same timeframe... how does it hurt that there is a 3.2 in
between????

Anyway, its all about three +1 votes, which I think we can muster
here, though there are a few technical problems and we will likely
need a respin, but thanks to the infra improvements dealing with
licensing and javadocs warnings and things like that, respinning is
only a matter of hours instead of a massive effort.

---------------------------------------------------------------------

Hi David,

On Sat, May 28, 2011 at 11:14 PM, David Smiley (@MITRE.org)
<[EMAIL PROTECTED]> 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 v3.2 waits for it, then 3.2
> will probably be at about the 3-month mark since the last release -- in my
> view (and Grant's) the ideal suite-spot for a release window.
>
> 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.

I can understand you point of view but I can't recall any release
without at least one person within the same situation.
We promised to spinn more frequent releases and we are trying to make
our best effort to do so. In order to eventually succeed with what we
have planned we need to make a start and get it going. Once we got the
release process running frequently and in predictable intervals folks
don't need to be in the situation you are in right now anymore. If
feature X somebody needs to have can not be in a certain release
because its pretty new and needs some time to bake its not going to be
a problem anymore since it will be in the next one which is reasonably
close. Let me tell you I have tons of features I would love to have in
4.0 but some of them might not make it for various reasons.
Yet, to get there it needs to be kicked off and I am super happy that
mike is doing it. We are changing lots of things here in the process
and we are expecting to step on peoples foot once in a while but look
at the amount of users this project has, you will always step on
somebody's foot, right?
As Robert pointed out this release has a couple of improvements 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 appreciate that you state your opinion on the grouping feature but
to be honest this has been developed within a couple of weeks with
great progress and lots of passion but I think its not ready to be
released and therefore it should not block it.

simon
>
> ~ David Smiley
>
> -----
>  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-tp2993434p2997968.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Sun, May 29, 2011 at 3:27 AM, Simon Willnauer
<[EMAIL PROTECTED]> 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 should consider
all of the following things:

* the list of features we have in 3.2 is actually digestible, its
probably bad to wait until we have this huge intimidating list of
changes to release, from casual browsing I don't see huge long lists
from other open source projects.
* if a user contributes something, I think its really important to
turn that around into a release faster, its going to encourage them to
contribute again. Sure, to those of us in the choir we are ok with
contributing stuff knowing its moving the project along long-term, but
I think for more casual contributors turn-around is really
important... they are most likely using releases not SVN and are
interested in when their contribution will be in a release.
* we have a growing list of committers and activity on the project and
I think speeding up the release cycle reflects our productivity level,
I think the list of features in 3.2 is quite nice and will benefit a
pretty large percentage of the userbase.
* we are talking about issuing off our stable branch, which has the
benefit of getting backports of things that have baked for a while in
trunk (e.g. TieredMP baked before being backported). We take the time
to maintain this stable branch, we should exploit it for all its worth
and get safe features out there.
* we are way more aggressive about bugs lately, its not just
patch+test, but instead, identify the general problem, fix it across
the board, and share the same mechanism with users to test their own
code (e.g. https://issues.apache.org/jira/browse/LUCENE-3147 and
https://issues.apache.org/jira/browse/LUCENE-3113 are some recent
examples of this)
* we did all this infra work to make releasing faster... its so much
better now, I can list all of the things I've done to validate/fixup
releases before (test under different locales, fix javadocs warnings,
license problems), and all of this stuff is automatic now.

So these are some of the reasons why I think it makes perfect sense to
try to crank out releases from our stable branch that are incremental
and evolutionary versus revolutionary.

---------------------------------------------------------------------

So I've looked over things fairly closely now. I saw a variety of things I'm not very concerned about that I dropped into IRC.

The only thing I am concerned about is that Solr does not use VERSION_32 in the example and so does not use the new Tiered
flush policy. I do think that's worth a respin (and wish I was more up to speed on signing and whats up with my keys and stuff so I could help out without as much investment as it would currently take).
- Mark
On May 27, 2011, at 11:50 AM, Michael McCandless wrote:

> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

- Mark Miller
lucidimagination.com

---------------------------------------------------------------------

+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 3.2 while they were closed after the RC (like LUCENE-3147) - should
we change their version to 3.3? Can we easily tell those issues?

LUCENE-3004 is marked a blocker for 3.2 - are we going to move it to 3.3 or
hold up 3.2?

There are 32 issues overall marked for 3.2 (that are still open) - I suggest
we bulk move all of them to 3.3 and then selectively update those that make
it into another RC (if one is produced).

Shai

On Fri, May 27, 2011 at 6:50 PM, Michael McCandless <
[EMAIL PROTECTED]> wrote:

> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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) That foo.txt - it is in the two binary files (not in the source one) - I
think it is not a show stopper - either remove it manually, or perhaps, to
make sure the released packs are the ones voted on, just note about it. If
removed manually I suggest at least one additional review of the packs and
their new check sums.

3) Lucene src pack contains SNOWBALL-LICENSE.txt which is not in either of
the two binary packages, is this a problem?

4) Lucene: lucene/contrib/benchmark/.rsync-filter is only in the source pack
(and in SVN), I was not aware of this file, though it was added long ago in
https://issues.apache.org/jira/browse/LUCENE-848?focusedCommentId=12491404&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12491404
Not a blocker for this RC, just interesting to note.

5) running 'ant clean' (or any target) from tarsrc/lucene-3.2.0 fails due to
dependency in ../common-build.xml.
I don't recall what was the decision about this in previous release (3.1) -
so not sure, is this a major problem, that the source pack is actually not
easily runnable? (I think it is, but again, almost sure this was already
discussed).

So I copied top common-build.xml from r1128276 (I gather this is the source
for this release, although it was not stated here, but at least this is what
the manifest for one of the lucene jars says). With this I am able to run
the tests, and all passed (XP).

At compiling there are various warning printed, I think it would be more
assuring for downloaders if the build runs without warning. These warnings
are not a stopper.

6) checked the md5 and sha1 signatures - ok for all 6 packs (3 solr, 3
lucene).

I would like to know what others think about points 3 and 5 above before I
vote on this RC.

Doron

On Fri, May 27, 2011 at 6:50 PM, Michael McCandless <
[EMAIL PROTECTED]> wrote:

> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Let's move it!

From:  Shai Erera <[EMAIL PROTECTED]>
Reply-To:  <[EMAIL PROTECTED]>
Date:  Mon, 30 May 2011 12:15:58 +0300
To:  <[EMAIL PROTECTED]>
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, 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 3.2 while they were closed after the RC (like LUCENE-3147) - should
we change their version to 3.3? Can we easily tell those issues?

LUCENE-3004 is marked a blocker for 3.2 - are we going to move it to 3.3 or
hold up 3.2?

There are 32 issues overall marked for 3.2 (that are still open) - I suggest
we bulk move all of them to 3.3 and then selectively update those that make
it into another RC (if one is produced).

Shai

On Fri, May 27, 2011 at 6:50 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> Please vote to release the artifacts at:
>
>   http://people.apache.org/~mikemccand/lucene_solr_320/rc1/
> <http://people.apache.org/%7Emikemccand/lucene_solr_320/rc1/>
>
> as Lucene 3.2.0 and Solr 3.2.0.
>
> Mike
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

On May 28, 2011, at 6:10 PM, Robert Muir wrote:

> On Sat, May 28, 2011 at 5:09 PM, Grant Ingersoll <[EMAIL PROTECTED]> 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 reminders on (as well as other Lucene related events) and then share it publicly (committers would have write access)
>>
>
> then my first commit would be to change this to monthly or more often.
>
> what are the technical reasons why we should not release this 3.2 candidate?

No reason, I was just commenting going forward...
---------------------------------------------------------------------

On Mon, May 30, 2011 at 5:15 AM, Shai Erera <[EMAIL PROTECTED]> 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 their Fix Version is still 3.2. Also, there are issues that are
> marked 3.2 while they were closed after the RC (like LUCENE-3147) - should
> we change their version to 3.3? Can we easily tell those issues?

As much as I love LUCENE-3147, I'm not sure if we should try to shove
code changes that aren't blockers into 3.2... it seems at a technical
level there aren't huge problems, but we (Mark, you, Doron, etc) have
found a number of packaging/documentation/configuration files issues
that we might want to address.

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

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 forgotten again rather than just
fixing it.

---------------------------------------------------------------------

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
release from there.

Shai

On Mon, May 30, 2011 at 10:52 PM, Robert Muir <[EMAIL PROTECTED]> wrote:

> On Mon, May 30, 2011 at 5:15 AM, Shai Erera <[EMAIL PROTECTED]> 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 their Fix Version is still 3.2. Also, there are issues that are
> > marked 3.2 while they were closed after the RC (like LUCENE-3147) -
> should
> > we change their version to 3.3? Can we easily tell those issues?
>
> As much as I love LUCENE-3147, I'm not sure if we should try to shove
> code changes that aren't blockers into 3.2... it seems at a technical
> level there aren't huge problems, but we (Mark, you, Doron, etc) have
> found a number of packaging/documentation/configuration files issues
> that we might want to address.
>
> 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
>
> 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 forgotten again rather than just
> fixing it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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 forgotten again rather than just
> fixing it.

+1

- Mark Miller
lucidimagination.com

BERLIN BUZZWORDS JUNE 6-7TH, 2011

---------------------------------------------------------------------

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 time.  So I'm -1 to the idea of ignoring problems because we don't want to hold back releases.  Re-spinning must remain a real option.

Another random thought: we have had a tradition of spending time fixing docs prior to a release.  I don't think this makes sense anymore: releasing should be as rote as possible.  But I don't think our docs should suffer as a result of this shift.  This implies that we should be looking harder at documentation when things get committed.  (This is a good thing.)
Lucene
------

Release blocking issues:

1. Snowball license:

 On 5/30/2011 at 8:22 AM, Doron Cohen wrote:
> 3) Lucene src pack contains SNOWBALL-LICENSE.txt which is
> not in either of the two binary packages, is this a problem?

-1 to RC1 based on this.  Unlike the other license files in the source distribution, which cover external .jar dependencies (in various lib/ directories in the source archive, but not in the release archives), the Snowball license covers content in the released Lucene binaries.

2. Source archive broken build:

> 5) running 'ant clean' (or any target) from tarsrc/lucene-3.2.0
> fails due to dependency in ../common-build.xml.

-1 to RC1 based on this.  The source tarball needs to be usable.  At present, nothing in the missing imported file is used in the Lucene build, so the <import> tag in lucene/common-build.xml could be removed.  Alternatively, adding the attribute optional="true" to the <import> tag allows the build to function.

3. Contrib Javadocs include links to removed contribs ant, db, lucli, and swing. -1 to RC1 based on this.

Non-blocking issues:

1. NOTICE.txt refers to .jar files and the corresponding LICENSE files in various lib/ directories, which are not included in the binary archives.  Should we have a way to automatically strip these things from the source NOTICE.txt to form a release NOTICE.txt?

2. CHANGES.txt has no release date for 3.1.0 - although we've stopped putting dates on RCs' CHANGES.txt for the release-to-be, we should add dates to CHANGES.txt for past releases.
Solr
----

Starting the example server and posting the example docs (following example/README.txt) works for me from the .tgz binary archive, as does building/running the tests from the source archive, though I had to switch to a 1.6 JVM to get the tests to complete - under Win7 with a 1.5 JVM, there were build failures related to file deletion problems.

Release blocking issues:

1. Default to the new Tiered flush policy:

On 5/29/2011 at 10:42 AM, Mark Miller wrote:
> The only thing I am concerned about is that Solr does not use
> VERSION_32 in the example and so does not use the new Tiered
> flush policy.  I do think that's worth a respin

I agree.  -1 to RC1 based on this.

2. All contrib/*/CHANGES.txt have "3.2-dev" as the release header.  -1 to RC1 based on this.

Steve
> -----Original Message-----
> From: Michael McCandless [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 27, 2011 11:50 AM
> To: [EMAIL PROTECTED] Dev
> Subject: [VOTE] Release Lucene/Solr 3.2.0
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 time.  So I'm -1 to the idea of ignoring problems because we don't want to hold back releases.  Re-spinning must remain a real option.
>

its not ignoring problems, but just because its a bug in packaging
doesnt immediately make it a blocker issue. many of these packaging
bugs are pre-existing conditions in 2.9, 3.0, 3.1, etc, and we
released those successfully just fine. Packaging bugs are bugs like
anything else, and packaging will never be perfect, we just have to
decide which are blockers.
>
> 3. Contrib Javadocs include links to removed contribs ant, db, lucli, and swing. -1 to RC1 based on this.

While I agree with most of the other things you said, I voice some
disagreement here. I'm not sure things like this in contrib should
block a release.

if its so important that it blocks a release, then it should be in our
core product.

That said, this one is trivial to fix, so lets fix it too for the next rc.

---------------------------------------------------------------------

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 that aren't blockers into 3.2...

-1 to including non-blocking issues in re-spun RCs.

> 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

On 5/30/2011 at 4:16 PM, Robert Muir wrote:
> On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > 3. Contrib Javadocs include links to removed contribs ant,
> > db, lucli, and swing. -1 to RC1 based on this.
>
> While I agree with most of the other things you said,
> I voice some disagreement here. I'm not sure things
> like this in contrib should block a release.
>
> if its so important that it blocks a release, then it
> should be in our core product.

IMHO, users won't make this distinction.  Advertising non-existent components is bad enough that it should block a release.

Steve

On Mon, May 30, 2011 at 4:25 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 trying to
improve things overall so we can release faster.
It says to "define a test plan"... we already have tests, so can I
simply mark the issue fixed?

This seems to be more of an ongoing issue, we always want to have more
defined tests to ensure everything is great, but we do in fact have
tests now and it shouldn't be a blocker that stops releases until some
volunteer decides to write more tests.

---------------------------------------------------------------------

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 freeze happens after n/2 days:
   * an RC is created at this point, to aid testing
   * only bugs/regressions found in RC will be committed
   * if others want to continue coding, a release branch can be
     created
   * if anyone commits code between 0 and n/2 days, they also commit to
     fixing reported bugs between n/2 and n days
 * Proposer can then roll the release and call for a vote when n days
   are up, assuming they are happy that all reported bugs are resolved

Getting a little more formal, we could have suggested approximate dates
on calendar, and folks could volunteer to take on those releases,
following the above process.

This would give folks warning to get code in that is 'nearly' finished,
yet prevent the release waiting on 'nearly finished' code. It would also
put most of the power to make the release into the hands of the release
manager.

Thoughts?

Upayavira
On Sat, 28 May 2011 17:09 -0400, "Grant Ingersoll" <[EMAIL PROTECTED]>
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 reminders
> on (as well as other Lucene related events) and then share it publicly
> (committers would have write access)
>
>
> On May 28, 2011, at 9:49 AM, Mark Miller wrote:
>
> > 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.
> >
> > Releases take 3 +1s - I'll give my +1 as often as someone puts artifacts in front of me and I have time to verify them.
> >
> > The worry of releasing TOO much is so premature it's not even funny :)
> >
> > Sent from my iPad
> >
> > On May 28, 2011, at 1:25 AM, "David Smiley (@MITRE.org)" <[EMAIL PROTECTED]> wrote:
> >
> >> 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 it feel worthwhile. And because we value stability and robustness in
> >> Lucene/Solr, changed code should have *some* amount of time to be
> >> potentially used and tested further.  And there's impact on the user
> >> community. If a release occurred too frequently then there might be very
> >> little meaningful improvements in the release. I believe it is Hudson (now
> >> Jenkins) that followed that extreme of I think releasing every week or so.
> >> It's so frequent that as an admin of such a server where I work, I don't
> >> even care to look at what's new in the releases because there are too many
> >> of them--I've become apathetic when I was initially excited to use it. So
> >> hopefully with each release there's something truly cool to tell others
> >> about in Lucene/Solr.  
> >>
> >> Gauging these factors is of course very subjective.  Personally, I think 3
> >> months is just right, 1 or less is too fast. Given that v3.1 was released 2
> >> months ago and there are some truly cool features like Result Grouping in
> >> Solr to announce in 3.2. I'm in favor of a release.
> >>
> >> ~ David Smiley
> >>
> >> -----
> >> 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-tp2993434p2995419.html
> >> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
Enterprise Search Consultant at Sourcesense UK,
Making Sense of Open Source

On Mon, May 30, 2011 at 4:25 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 for every thing people found (please
check and see if i forgot anything you found!!!)

I marked these all as fix version 3.3/4.0, though we might want to
make some of them blockers for 3.2 (depending upon discussion).

So these are all tagged 'maybe32blocker' for convenience... please
check and make sure I didn't forget anything:

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+maybe32blocker

---------------------------------------------------------------------

On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 release?

---------------------------------------------------------------------

I suggest you stick this on the Wiki and make it more official if people +1 this
approach.  Otherwise it will get forgotten and will be hard to reference.

Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/

----- Original Message ----
> From: Upayavira <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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 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 freeze happens after n/2 days:
>    * an RC is created at this point,  to aid testing
>    * only bugs/regressions found in RC will be  committed
>    * if others want to continue coding, a release branch can  be
>      created
>    * if anyone commits code between 0 and  n/2 days, they also commit to
>      fixing reported bugs between n/2  and n days
>  * Proposer can then roll the release and call for a vote when n  days
>    are up, assuming they are happy that all reported bugs are  resolved
>
> Getting a little more formal, we could have suggested  approximate dates
> on calendar, and folks could volunteer to take on those  releases,
> following the above process.
>
> This would give folks warning  to get code in that is 'nearly' finished,
> yet prevent the release waiting on  'nearly finished' code. It would also
> put most of the power to make the  release into the hands of the  release
> manager.
>
> Thoughts?
>
> Upayavira
>
>
> On Sat, 28 May  2011 17:09 -0400, "Grant Ingersoll" <[EMAIL PROTECTED]>
> 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 reminders
> > on (as well as other Lucene related  events) and then share it publicly
> > (committers would have write  access)
> >
> >
> > On May 28, 2011, at 9:49 AM, Mark Miller  wrote:
> >
> > > 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.
>
> > >
> > > Releases take 3 +1s - I'll give my +1 as often as  someone puts artifacts
>in front of me and I have time to verify them.
>
> >  >
> > > The worry of releasing TOO much is so premature it's not even  funny :)
> > >
> > > Sent from my iPad
> > >
> > >  On May 28, 2011, at 1:25 AM, "David Smiley (@MITRE.org)"
><[EMAIL PROTECTED]> wrote:
> > >
> > >> 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 it feel worthwhile. And because we value stability and  robustness
in
> > >> Lucene/Solr, changed code should have *some*  amount of time to be
> > >> potentially used and tested further.   And there's impact on the user
> > >> community. If a release occurred  too frequently then there might be very
> > >> little meaningful  improvements in the release. I believe it is Hudson
>(now
> > >>  Jenkins) that followed that extreme of I think releasing every week or  
>so.
> > >> It's so frequent that as an admin of such a server where I  work, I don't
> > >> even care to look at what's new in the releases  because there are too
>many
> > >> of them--I've become apathetic when  I was initially excited to use it.
So
> > >> hopefully with each  release there's something truly cool to tell others

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.

> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 30, 2011 6:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] Release Lucene/Solr 3.2.0
>
> On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 release?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

On Mon, May 30, 2011 at 9:20 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 lot of bugs (known
and unknown) with lucene. really releases need to be incremental
improvements, only really serious shit (like index corruption or
broken licensing or something) should be blockers IMO.

lots of the things mentioned here have been broken for a long time (i
have a lucene-2.4.0 checkout I am looking at just for fun).

---------------------------------------------------------------------

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 pull the trigger given people's concerns and 3 +1 votes. If 3 PMC members feel a release is worthy, and are not willing to pull those votes - delaying the release any further is a very hard argument to make. There is a reason there is not a veto on release - it can take a long time to make *everyone* happy. We have seen it again and again. We want to make everyone happy. But we also want to get a slick and fast release processes down - and that means trying something a bit different than we have in the past if you ask me.

If someone is really concerned about an issue, and cannot get others on board, they are free (and I'd say encouraged) to roll there own release candidate and offer it up for vote.

Lets still put things on the table. Lets still respin when we think we have to. But also, lets *push* to release.

That's not to say we should not do respins, or consider all issues others want to put on the table. But we all know the release history and the release dilemma. It's as old as I've been here.

I agree with Robert. This release will be better than the last. The next will be better than this one.

- Mark

On May 30, 2011, at 9:27 PM, Robert Muir wrote:

> On Mon, May 30, 2011 at 9:20 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 lot of bugs (known
> and unknown) with lucene. really releases need to be incremental
> improvements, only really serious shit (like index corruption or
> broken licensing or something) should be blockers IMO.
>
> lots of the things mentioned here have been broken for a long time (i
> have a lucene-2.4.0 checkout I am looking at just for fun).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

- Mark Miller
lucidimagination.com

BERLIN BUZZWORDS JUNE 6-7TH, 2011

---------------------------------------------------------------------

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 <[EMAIL PROTECTED]> wrote:
>
> On May 28, 2011, at 6:10 PM, Robert Muir wrote:
>
>> On Sat, May 28, 2011 at 5:09 PM, Grant Ingersoll <[EMAIL PROTECTED]> 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 reminders on (as well as other Lucene related events) and then share it publicly (committers would have write access)
>>>
>>
>> then my first commit would be to change this to monthly or more often.
>>
>> what are the technical reasons why we should not release this 3.2 candidate?
>
> No reason, I was just commenting going forward...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------