On Wed, Mar 9, 2011 at 5:03 AM, Uwe Schindler u...@thetaphi.de wrote:
All problems seem to be solved now:
- Clover's use of X/freetype works (broken openjdk installation fixed)
- Compile error in those antique JDK 1.5 (because of ugly casts) resolved by
removing some generics in
By the way, I've been seeing this for a while in my local (this test
often causes my jre to crash).
So its nothing wrong with hudson, I just thought it might have been my
computer since nobody else complained.
On Wed, Mar 9, 2011 at 12:13 PM, Apache Hudson Server
hud...@hudson.apache.org wrote:
On Thu, Mar 10, 2011 at 6:49 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Can you open an issue? Make sure it's marked fix 4.0/3.2! Thanks.
I'm not sure we should handle it this way: I really don't like
deprecation in one release and undeprecation in another.
So, I think we should
On Thu, Mar 10, 2011 at 7:41 AM, Shay Banon kim...@gmail.com wrote:
I am not sure that IndexWriterConfig is bad. Its nice to be able to set all
the upfront configurations in a single object and pass it to the
IndexWriter. And, have the IndexWriter allow for specific setters allowing
for real
Thanks for the review hoss... the rest of this stuff should surely be
fixed (FYI won't be by me, I did my time)
I only had one comment.
exist -- dist and docs. Looking at the tutorial, i noticed the first
glitch: it lists the Solr version as 3.0.0.2011.03.06.20.12.33 (which i
know means it
On Thu, Mar 10, 2011 at 9:03 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
The way it gets into the solr docs is via a property file generated by the
build (see the init-forrest-entities, it's setup as a dependency for just
about everything) that forrest then reads. the old release
Sorry, was trying to upgrade openjdk (from b20 to b22) to hopefully
get past our jvm crashes in tests.
The problem is that we cannot do this without having procfs mounted,
as b22 now requires this for the native freebsd version.
On Sun, Mar 13, 2011 at 11:47 AM, Grant Ingersoll gsing...@apache.org wrote:
I guess the question people w/ Solr only hats on have (if there are such
people), is which way is that street going? It seems like most people want
to pull stuff out of Solr, but they don't seem to want to put into
On Thu, Mar 17, 2011 at 7:09 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
Lucene Artifacts...
* ant javadocs fails because javadocs-all can't find prettify...
BUILD FAILED
/home/hossman/tmp/lucene3.1rc/3.1.rc1/l-src-tgz/lucene-3.1.0/build.xml:206:
The following error occurred
On Fri, Mar 18, 2011 at 8:50 AM, Steven A Rowe sar...@syr.edu wrote:
On 3/18/2011 at 7:37 AM, Robert Muir wrote:
I don't like that the lucene build from the source release is broken.
https://issues.apache.org/jira/browse/LUCENE-2973 fixes it by including
dev-tools (and everything else except
On Mon, Mar 21, 2011 at 11:21 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
Anyone see a downside?
I don't think we should do anything serious in a gc finalizer.
sounds like its asking for a JRE crash.
-
To
On Mar 22, 2011 11:38 PM, Ryan McKinley ryan...@gmail.com wrote:
I'm messing with putting binary data directly in the index. I have a
field class with:
@Override
public TokenStream tokenStreamValue() {
byte[] value = (byte[])fieldsData;
Token token = new Token( 0, value.length,
On Thu, Mar 24, 2011 at 12:18 AM, Ryan McKinley ryan...@gmail.com wrote:
I don't want to suggest anything to slow down the release... but if
the problems are with the source release, what about just doing a
single source release for lucene+solr?
We currently have:
On Thu, Mar 24, 2011 at 2:28 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: The issue is a bug in IBM's Collections class. The List returned by
: emptyList() does not implement RandomAccess.
:
: I fixed the test (unfortunately it's clear that emptyList() should
: return a random
On Thu, Mar 24, 2011 at 6:19 PM, Uwe Schindler u...@thetaphi.de wrote:
Hi,
* MultiSearcher is deprecated; ParallelMultiSearcher has been
absorbed directly into IndexSearcher
That's trunk only? I did not notice that IndexSearcher was changed?
its in 3.1 too. The IndexSearcher can take
On Fri, Mar 25, 2011 at 10:18 AM, Mark Miller markrmil...@gmail.com wrote:
Well, actually I think we should just make it completely unsupported. These
are our dev tools - don't count on them for crap. No reason to exclude them
from the src IMO.
For the solr release, I think I could be ok
On Fri, Mar 25, 2011 at 10:45 AM, Grant Ingersoll gsing...@apache.org wrote:
I do think we need standalone artifacts. So, I suppose if we do that, then
we can't just svn export, b/c we would need to separate dev tools per
project. But, then again, why can't we have:
/dev-tools/
On Fri, Mar 25, 2011 at 11:04 AM, Grant Ingersoll gsing...@apache.org wrote:
So I don't think this is useful: dev-tools is for developers,
So now its a broken build system if it DOESNT include a working
ide-configurator? This is what I meant by slippery slope
On Fri, Mar 25, 2011 at 11:11 AM, Grant Ingersoll gsing...@apache.org wrote:
No, as Hoss pointed out, it's broken now w/o the ide configurator!
Right, but my original suggestion (include dev-tools in the solr
release, because its the whole trunk) will fix that.
Alternatively we could remove the
On Sat, Mar 26, 2011 at 9:48 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Sat, Mar 26, 2011 at 7:32 AM, Robert Muir (JIRA) j...@apache.org wrote:
I don't really think things like this (queries etc) should go into just Solr
I disagree strongly with the sentiment that queries don't
a couple quick suggestions inline:
On Sat, Mar 26, 2011 at 10:07 PM, Grant Ingersoll gsing...@apache.org wrote:
Proposed Release Announcement (edits welcome). Also note we can have ASF
Marketing put out a press release if we want.
snip
March 2011, Lucene 3.1 available
The Lucene PMC is
the real question is: why is this fixed only in the 3.1 branch?
how did our 3.1 branch and 3.x/trunk get so different? I don't like
that any work done to get 3.1 out the door is going to be lost and
have to be re-done.
On Sun, Mar 27, 2011 at 5:26 PM, Andi Vajda va...@osafoundation.org wrote:
On Mon, Mar 28, 2011 at 10:54 AM, Uwe Schindler u...@thetaphi.de wrote:
Hi,
If we we have to rebuild the artifacts, should we add Shai/Mike's
addIndexes() fix, too?
3.1 branch is fine with regards to this issue, thats why I raised my
question... it seems only the 3.1 release branch was fixed
FYI this is a relatively new test, and I think its a bug in IBM's jre.
I found similar problems in ICU and i know IBM JRE's intl impl is
different than sun's (maybe a newer icu version?)
I worked around these in the icu collation tests, and we might have to
do the same here... we can't use
personally I like the existing behavior for a lot of purposes though.
when i'm trying to write a test for a bug, i use X=100 and look at the
failure percentage.
On Tue, Mar 29, 2011 at 4:45 AM, Shai Erera ser...@gmail.com wrote:
If I set tests.iter=X, then the test runs X times, even if an
On Tue, Mar 29, 2011 at 8:40 AM, Shai Erera ser...@gmail.com wrote:
I see. On the other hand, it's a bit annoying when you run with X=100 for
the purpose of catching a multi-threaded bug, which occurs after the 2nd
iteration ...
Yea I want both options too, just saying I want to somehow keep
On Wed, Mar 30, 2011 at 8:22 AM, Grant Ingersoll gsing...@apache.org wrote:
(Long post, please bear with me and please read!)
Now that we have the release done (I'm working through the publication
process now), I want to start the process of thinking about how we can
improve the release
yes, the collation tests work the same way, as they use pure binary tokens.
so their tests look like this:
@Override
public void setUp() throws Exception {
super.setUp();
assumeFalse(preflex format only supports UTF-8 encoded bytes,
On Wed, Mar 30, 2011 at 4:15 PM, Ryan McKinley ryan...@gmail.com wrote:
thanks -- I also see it failing on SimpleText. Is that expected?
I don't think that is expected? The collation keys use binary terms in
their tests and pass with simpletext, though that doesn't mean their
isn't a
On Wed, Mar 30, 2011 at 4:22 PM, Ryan McKinley ryan...@gmail.com wrote:
int off = ref.offset;
...
if (off + buf.length ref.length) {
throw new InvalidShapeException(Asking for too many bytes);
this check looks like it might be wrong (backwards logic)
On Wed, Mar 30, 2011 at 4:49 PM, Burton-West, Tom tburt...@umich.edu wrote:
I would like to be able to use the Lucene Benchmark code with Solr to run
some indexing tests. It would be nice if Lucene Benchmark to could read
Solr configuration rather than having to translate my filter chain and
On Thu, Mar 31, 2011 at 9:40 AM, Upayavira u...@odoko.co.uk wrote:
Are you willing to say more? I have a little time, and have done a lot
of work with Ant. Maybe I could help.
Upayavira
Thanks, there is some followup discussion on this JIRA issue:
On Thu, Mar 31, 2011 at 9:51 AM, Patrick ALLAERT
patrick.alla...@gmail.com wrote:
Hello,
Facing a Solr issue, I have been told that queries with a term like:
Kiinteistösih*
will not match the Finnish word Kiinteistösihteeri and that it's a
known limitation of Lucene.
Instead, using the word
On Thu, Mar 31, 2011 at 11:24 AM, Burton-West, Tom tburt...@umich.edu wrote:
Thanks Robert and Grant,
Does this need a separate JIRA issue dealing specifically with the ability of
benchmark to read Solr config settings, or is it subsumed in LUCENE-2845? or
should I just add a comment to
On Thu, Mar 31, 2011 at 12:07 PM, Christopher St John
ckstj...@gmail.com wrote:
On the front page, in the announcement:
News 31 March 2011 - Lucene Core 3.1 and Solr 3.1 Available The Lucene
PMC is... after Solr 1.4.1. Lucene can be downloaded from:
The Lucene download link says /java put
On Fri, Apr 1, 2011 at 7:58 AM, Dawid Weiss dawid.we...@gmail.com wrote:
Mike, can you remember what ordering is required for
add(CharSequence)? I see it requires INPUT_TYPE.BYTE4
assert fst.getInputType() == FST.INPUT_TYPE.BYTE4;
but this would imply the order of full unicode codepoints on
On Fri, Apr 1, 2011 at 8:25 AM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Yes, this is what I also figured out. The unicode code point order is
also impl. in BytesRef.getUTF8SortedAsUnicodeComparator, correct? For
what I need I'll use raw utf8 byte order, it doesn't matter as long as
On Fri, Apr 1, 2011 at 8:31 AM, Shai Erera ser...@gmail.com wrote:
Hi
I noticed that 3.1.0's tag in svn is
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_1. Should it
not be http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_1_0? At
least, that's what's specified
On Fri, Apr 1, 2011 at 8:42 AM, Robert Muir rcm...@gmail.com wrote:
On Fri, Apr 1, 2011 at 8:31 AM, Shai Erera ser...@gmail.com wrote:
Hi
I noticed that 3.1.0's tag in svn is
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_1. Should it
not be http://svn.apache.org/repos/asf
On Fri, Apr 1, 2011 at 8:49 AM, Shai Erera ser...@gmail.com wrote:
The branch is ok -- 3_1 branch is intended for 3.1.x future releases indeed.
If we can commit to releasing 3.2 instead of 3.1.1 in case only bug fixes
are present, then I'm ok with it. We'd also need to commit, in general, to
On Fri, Apr 1, 2011 at 10:00 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Fri, Apr 1, 2011 at 9:22 AM, Jan Høydahl jan@cominvent.com wrote:
Testing the new Solr 3.1 release under Windows XP and Java 1.6.0_23
When trying to post example\exampledocs\gb18030-example.xml using
On Wed, Apr 6, 2011 at 2:12 PM, Ryan McKinley ryan...@gmail.com wrote:
Some may be following the thread on spatial development... here is a
quick summary, and a poll to help decide what may be the best next
move.
I'm hoping to introduce a high level spatial API that can be used for
a
On Wed, Apr 6, 2011 at 2:54 PM, Ryan McKinley ryan...@gmail.com wrote:
The code can be separated so that the the dependencies are as you
suggest -- i have done this, but it makes testing more difficult and
less robust. As part of the framework I've introduced a robust way to
use the same
On Wed, Apr 6, 2011 at 5:07 PM, Earwin Burrfoot ear...@gmail.com wrote:
Handling Unicode code points outside of BMP is highly expert stuff as
well. And is totally unneeded by 80% of the users for any other reason
except elegance. I think you two guys can really understand each
other here : )
On Thu, Apr 7, 2011 at 4:27 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
replying to dev...
: in eclipse you need to set your project's character encoding to UTF-8.
...
: Some language specific classes like GermanLightStemmer has invalid
: character
: compiler errors for
On Thu, Apr 7, 2011 at 6:48 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: -1. These files should be readable, for maintaining, debugging and
: knowing whats going on.
Readability is my main concern ... i don't know (and frequently can't
tell) the differnece between a lot of non ascii
On Fri, Apr 8, 2011 at 2:49 AM, Earwin Burrfoot ear...@gmail.com wrote:
On Fri, Apr 8, 2011 at 03:01, Robert Muir rcm...@gmail.com wrote:
On Thu, Apr 7, 2011 at 6:48 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: -1. These files should be readable, for maintaining, debugging
to
change the rules, not just blithely ignoring them because you don't feel
like following them.
Unhappily,
Steve
-Original Message-
From: DM Smith [mailto:dmsmith...@gmail.com]
Sent: Friday, April 15, 2011 9:31 AM
To: dev@lucene.apache.org
Subject: Re: Robert Muir thinks we should
On Thu, Apr 21, 2011 at 3:42 AM, Uwe Schindler u...@thetaphi.de wrote:
OK,
I was not aware that you took action, too. Because there is the message
about Jenkins shutdown, I was assuming that you are fixing the master.
About the Lucene slave, the problem we have is: Our tests need lots of
On Fri, Apr 22, 2011 at 9:13 AM, Uwe Schindler u...@thetaphi.de wrote:
Hi Robert,
Thanks for pointing to that issue. Indeed the leftover test files in Lucene
take approx. 3 GB per build. With our 9 builds that’s 30 GB - useless. If the
tests clean up the thing successfully after running, we
On Sat, Apr 23, 2011 at 4:17 AM, Simon Willnauer
simon.willna...@googlemail.com wrote:
Addition:
I meant such code to be replaced:
- indexDir = new File(workDir, testIndex);
+ indexDir = _TestUtil.getTempDir(testIndex);
Thanks for merging Simon!
also, for what its worth, we
On Sat, Apr 23, 2011 at 6:27 PM, Uwe Schindler u...@thetaphi.de wrote:
Hi Robert,
On Hudson there is still one very bad test, all others are cleaned up:
[root@lucene
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/test/4]#
ls -lh
total 1286544
On Sat, Apr 23, 2011 at 6:27 PM, Uwe Schindler u...@thetaphi.de wrote:
Hi Robert,
On Hudson there is still one very bad test, all others are cleaned up:
[root@lucene
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/test/4]#
ls -lh
total 1286544
On Sat, Apr 23, 2011 at 6:40 PM, Robert Muir rcm...@gmail.com wrote:
I thought i did this already, but maybe i screwed it up
Sorry, silly test bug... fixed in Revision: 1096249
-
To unsubscribe, e-mail: dev-unsubscr
Hi,
It appears there are some problems with modularization of the code,
especially between lucene and solr, so I would like for us to have a
discussion on this thread.
The two sides/takes seem to be (with some example reasons):
1. pro: for example, modularization can expose features that were
On Tue, Apr 26, 2011 at 11:41 PM, Grant Ingersoll gsing...@apache.org wrote:
I think this needs a bit more explanation. AIUI, the primary cause for
concern is that by making something a module, you are taking a private,
internal API of Solr's and now making it a public API that must be
On Wed, Apr 27, 2011 at 8:13 AM, Mark Miller markrmil...@gmail.com wrote:
The problem is that Simon says things like, everything should be a module and
solr should just be sugar on Lucene. That scares Yonik. Then Yonik makes
comments questioning individual modules. That scares the other
false fail caused by LUCENE-3053, I'll fix.
On Sun, May 1, 2011 at 11:02 AM, Apache Jenkins Server
hud...@hudson.apache.org wrote:
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7613/
1 tests failed.
REGRESSION:
This is likely also caused by LUCENE-3053... will take a look now
On Sun, May 1, 2011 at 11:22 AM, Apache Jenkins Server
hud...@hudson.apache.org wrote:
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7614/
1 tests failed.
FAILED:
This is fixed in r1098359.
this realtime capability of instantiated is incompatible with
MultiReader, because when MR initializes it computes and caches the
maxDoc, which becomes out of date with respect to the
InstantiatedIndexReader if you use it in this way.
The only reason the test didnt
fixed in revision 1098372.
On Sun, May 1, 2011 at 1:13 PM, Apache Jenkins Server
hud...@hudson.apache.org wrote:
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7618/
1 tests failed.
REGRESSION: org.apache.lucene.search.TestTermScorer.testNext
Error Message:
null
this one is somehow triggered by LUCENE-3057
On Sun, May 1, 2011 at 1:28 PM, Apache Jenkins Server
hud...@hudson.apache.org wrote:
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/7620/
1 tests failed.
REGRESSION:
On Mon, May 2, 2011 at 6:43 AM, Michael McCandless
luc...@mikemccandless.com wrote:
I slurped this hprof down and opened it w/ YourKit...
Something weird is going on, because there is a single massive (151
MB) string, stack local to one of the threads, filled with character
U+00B2.
The test
On Mon, May 2, 2011 at 6:43 AM, Michael McCandless
luc...@mikemccandless.com wrote:
I slurped this hprof down and opened it w/ YourKit...
Something weird is going on, because there is a single massive (151
MB) string, stack local to one of the threads, filled with character
U+00B2.
The test
On Wed, May 4, 2011 at 9:11 AM, Mark Miller markrmil...@gmail.com wrote:
Side note (plug): I have been playing with the benchmark module (who did that
module? I had missed it), and I've got some cool stuff to show at Berlin
Buzzwords this year for my solr performance talk!
we svn move'd it
Hi Uwe,
I think we should open an issue to clean some of this up (I know i am
at fault for some of it)
Recently, i worked with this test some and also found these problems:
* when creating the backwards test index, we should not lowercase. the
test expects to be able to do term-queries on
On Sat, May 7, 2011 at 8:39 AM, Uwe Schindler u...@thetaphi.de wrote:
I agree. We should maybe factor out the createIndex method at all to a
separate class that also automatically ZIPs the index after creating it.
createIndex method is not really a test, it’s a utility to produce the
On Sun, May 15, 2011 at 12:05 PM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
In the Field object a text value must be of type string, however I
think we can allow a BytesRef to be passed in?
it would be nice if we sorted them in byte order too? I think right
now fields are sorted in
On Mon, May 16, 2011 at 7:52 AM, Simon Willnauer
simon.willna...@googlemail.com wrote:
Hey folks,
we just started the discussion about Lucene 3.2 and releasing more
often. Yet, I think we should also start planning for Lucene 4.0 soon.
We have tons of stuff in trunk that people want to have
On Mon, May 16, 2011 at 8:48 AM, Uwe Schindler u...@thetaphi.de wrote:
Sorry to be negative,
- BulkPostings (my +1 since I want to enable positional scoring on all
queries)
My problem is the really crappy and unusable API of BulkPostings (wait for my
talk at Lucene Rev...). For anybody
On Mon, May 16, 2011 at 9:12 AM, Simon Willnauer
simon.willna...@googlemail.com wrote:
I have to admit that branch is very rough and the API is super hard to
use. For now!
Lets not be dragged away into discussion how this API should look like
there will be time
for that.
+1, this is what i
On Mon, May 16, 2011 at 11:29 AM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
But when you create an untokenized field (or even a binary field, which is
stored-only at the moment), you could theoretically index the bytes directly
Right, if I already have a BytesRef of what needs to be
On Mon, May 16, 2011 at 7:41 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
I don't disagree, but the devils advocate argument is given the relative
size of the change sets, testing a 3.1.1 release is likely to be easier
then testing a 3.2 release, and the patches commited to the 3.1.x
On Tue, May 17, 2011 at 3:38 PM, Marvin Humphrey mar...@rectangular.com wrote:
On Tue, May 17, 2011 at 03:09:31PM -0400, Michael McCandless wrote:
Yeah I agree... build failures should be as annoying as possible ;)
Congratulations -- mission accomplished! They are certainly annoying to me,
On Wed, May 18, 2011 at 11:31 AM, Michael McCandless
luc...@mikemccandless.com wrote:
I think it's resolved now? Sorry!
But it's great we now catch jdoc errors before releasing... should we
fix our while(1) test to also catch this (not just nightly / maven)?
yeah couldn't we just fire off
On Wed, May 18, 2011 at 11:44 AM, Uwe Schindler u...@thetaphi.de wrote:
Hi,
Definitely not. Javadocs-all takes 2 minutes here, so please don’t bundle it
with compile, I will stop working on Lucene then, that does not help during
development (I use no Eclipse to develop...).
We can trigger
2011/5/19 Michael McCandless luc...@mikemccandless.com:
Of course, for
certain apps that perf hit is justified, so probably we should make
this an option when populating field cache (ie, in-memory storage
option of using an FST vs using packed ints/byte[]).
or should we actually try to have
On Fri, May 20, 2011 at 2:59 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
If we're serious about wanting to do a 3.2 release sometime in June, the
first step is to get proactive abour pruning down the roadmap of issues that
aren't going to make the cut.
Here's a list of every
On Fri, May 20, 2011 at 3:14 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: I suggest that we un-mark these for 3.2 this weekend. If you really feel
: strongly that something on this list needs to make it into 3.2, assign it
to
: yourself.
:
: +1, maybe we should make a 3.3 in
On Mon, May 23, 2011 at 11:08 AM, Shai Erera ser...@gmail.com wrote:
Version might be a good idea. Version also has onOrAfter (compare) method,
which if we'll use for SI.getVersion, will make
StringHelper.versionComparator moot?
Today we write a String (x.y) as the segment's version. We can
+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
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
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!
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
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.
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
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
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 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
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
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
Please vote to release the artifacts at http://s.apache.org/lusolr32rc2 as 3.2.0
Changes from rc1 are mostly packaging issues that testers found:
* SOLR-2557 ensure example configuration files have the correct
LUCENE_MATCH_VERSION
* SOLR-2558 remove apache lucene version from solr
On Tue, May 31, 2011 at 2:44 AM, Steven A Rowe sar...@syr.edu wrote:
I want to add all pre-1.9 Lucene releases to this page:
https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project:versions-panelsubset=-1
but I don't see any UI elements to add
On Tue, May 31, 2011 at 8:01 AM, Shai Erera ser...@gmail.com wrote:
I don't think it's a showstopper b/c the docs work fine in the binary
release, though it'd be good if we can fix that somehow for future releases.
I don't like inconsistencies. Maybe we should remove all docs and generate
them
On Tue, May 31, 2011 at 8:34 AM, Shai Erera ser...@gmail.com wrote:
BTW, I tried ant prepare-release from src and it doesn't work b/c of
get-svn-info which makes sense because this is not a svn checkout. But
maybe we can have it not fail on errors? I.e., if I run ant jar then the
.jars are
On Tue, May 31, 2011 at 10:19 AM, Koji Sekiguchi k...@r.email.ne.jp wrote:
+1 to release. Great work!
I saw a trivial issue in solr bin package (apache-solr-3.2.0.tgz).
I cannot find any script files for backup/replication (e.g. abc, snappuller,
snapinstaller,...).
Is this intentional or
On Wed, Jun 1, 2011 at 11:21 AM, Ryan McKinley ryan...@gmail.com wrote:
I know we have talked about this a few times, but not sure where we left off.
My understanding was that if we change something in trunk and merge to
3.x we *only* add it to the 3.x CHANGES. If it is only for 4.x it
gets
Welcome Martijn!
On Wed, Jun 1, 2011 at 3:01 PM, Michael McCandless
luc...@mikemccandless.com wrote:
The Lucene PMC has voted to add Martijn van Groningen as a Lucene/Solr
committer.
The traditional initiation ritual is to introduce yourself with a
brief bio of how it is you came to join us
1 - 100 of 17291 matches
Mail list logo
