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
+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
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)
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
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
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
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
/*/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
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
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
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
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
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
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
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
@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
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
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
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
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.
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
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
+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
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!
-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
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
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
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.
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
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
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
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
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
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:
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
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
+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:
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
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
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
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
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
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
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
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
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
46 matches
Mail list logo