OK, I created https://svn.apache.org/repos/asf/lucene/java/dist and
have committed the KEYS file from the last release. I also updated
http://wiki.apache.org/jakarta-lucene/ReleaseTodo to reference the url.
On Feb 21, 2007, at 12:38 PM, Doug Cutting wrote:
Chris Hostetter wrote:
: since
Chris Hostetter wrote:
: since we have different sets of committers for different sub-projects,
: it probably makes more sense to have per-subproject KEYS files. That
: way folks can add their own keys without altering our current permission
: scheme.
yeah, it would certianly be a "paradigm shi
: since we have different sets of committers for different sub-projects,
: it probably makes more sense to have per-subproject KEYS files. That
: way folks can add their own keys without altering our current permission
: scheme.
yeah, it would certianly be a "paradigm shift" ... i suggested it o
Chris Hostetter wrote:
: http://svn.apache.org/lucene/java/dist/ doesn't work for me. I do
: see the file on people.a.o as Hoss said.
1) i think doug was refering to the philosophical subversion location,
corrisponding ot the literal location of
http://svn.apache.org/repos/asf/lucene/java/dist
On Feb 20, 2007, at 1:07 PM, Chris Hostetter wrote:
: http://svn.apache.org/lucene/java/dist/ doesn't work for me. I do
: see the file on people.a.o as Hoss said.
1) i think doug was refering to the philosophical subversion location,
corrisponding ot the literal location of
http://svn.apach
: http://svn.apache.org/lucene/java/dist/ doesn't work for me. I do
: see the file on people.a.o as Hoss said.
1) i think doug was refering to the philosophical subversion location,
corrisponding ot the literal location of
http://svn.apache.org/repos/asf/lucene/java/dist/
2) it doesn't exist,
http://svn.apache.org/lucene/java/dist/ doesn't work for me. I do
see the file on people.a.o as Hoss said.
I thought I would try to familiarize myself more with the release
process, so that the burden can be shared and we can do it more
frequently, if desired.
On Feb 19, 2007, at 5:55 P
Chris Hostetter wrote:
: Don't know what that one is about. It also isn't clear to me where
: the KEYS file is to edit.
as far as i have ben able to figure out, the authoritative home of the
KEYS file is people.apache.org:/www/www.apache.org/dist/lucene/java/KEYS
Yes, and KEYS should be in sv
: Don't know what that one is about. It also isn't clear to me where
: the KEYS file is to edit.
as far as i have ben able to figure out, the authoritative home of the
KEYS file is people.apache.org:/www/www.apache.org/dist/lucene/java/KEYS
-Hoss
-
That looks a lot cleaner
On Feb 17, 2007, at 10:58 PM, Yonik Seeley wrote:
Well, I made a number of improvements (some of the stuff looked
really old).
Unless there is something Lucene specific though, perhaps we should
just point to Solr's or Hadoop's guide.
-Yonik
On 2/13/07, Grant Ingers
Don't know what that one is about. It also isn't clear to me where
the KEYS file is to edit.
On Feb 17, 2007, at 10:40 PM, Yonik Seeley wrote:
What's this? (the symlink part)
10. Update the symlinks in the release directory. If this is your
first release, add your key to the KEYS file.
-Y
Well, I made a number of improvements (some of the stuff looked really old).
Unless there is something Lucene specific though, perhaps we should
just point to Solr's or Hadoop's guide.
-Yonik
On 2/13/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
Hey Yonik,
Can you make sure the release docume
What's this? (the symlink part)
10. Update the symlinks in the release directory. If this is your
first release, add your key to the KEYS file.
-Yonik
On 2/13/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
Hey Yonik,
Can you make sure the release documentation on the wiki is inline
with what
Hey Yonik,
Can you make sure the release documentation on the wiki is inline
with what you have to do? I know I had to make some changes for the
website stuff and it may not be 100% correct b/c I didn't run it (#12
at http://wiki.apache.org/jakarta-lucene/ReleaseTodo). Also, you
double
OK folks, please try out the current trunk and see if you see any
problems, or other *bugs* in JIRA that need to go in.
I'll start work on cutting a release tomorrow.
-Yonik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
OK, now that LUCENE-565 is also done, I think we can finally get the
2.1 release process going?
Mike
Grant Ingersoll wrote:
OK, I'm now +1 on release
On Feb 1, 2007, at 6:57 AM, Grant Ingersoll wrote:
-1
I would like a few more days to get
https://issues.apache.org/jira/browse/LUCENE-762
OK, I'm now +1 on release
On Feb 1, 2007, at 6:57 AM, Grant Ingersoll wrote:
-1
I would like a few more days to get https://issues.apache.org/jira/
browse/LUCENE-762, as it may involve moving some classes and I
don't want to do that after an official release. It is not a major
issue, bu
MAIL PROTECTED]
Sent: Thursday, February 01, 2007 3:57 AM
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.1, soon
-1
I would like a few more days to get https://issues.apache.org/jira/
browse/LUCENE-762, as it may involve moving some classes and I don't
want to do that after an official release.
a-dev@lucene.apache.org
Subject: Re: Lucene 2.1, soon
-1
I would like a few more days to get https://issues.apache.org/jira/
browse/LUCENE-762, as it may involve moving some classes and I don't
want to do that after an official release. It is not a major issue,
but I do think it is import
Michael Busch wrote:
Michael McCandless wrote:
I plan on committing this one today. Once that's in I think we can
and should get the release process going (Yonik had graciously
volunteered to be the release manager)?
+1 for starting the release process. Especially the big new features
"lazy
-1
I would like a few more days to get https://issues.apache.org/jira/
browse/LUCENE-762, as it may involve moving some classes and I don't
want to do that after an official release. It is not a major issue,
but I do think it is important to get right before the release.
Sorry for the de
Michael McCandless wrote:
I plan on committing this one today. Once that's in I think we can
and should get the release process going (Yonik had graciously
volunteered to be the release manager)?
+1 for starting the release process. Especially the big new features
"lazy field loading", "lock
Antony Bowesman wrote:
Yonik Seeley wrote:
Lucene 2.1 has been a long time in coming, but I think we should plan
on making a release when the file format changes settle down.
Was there any kind of consensus of what 'soon' meant. Is it likely to
be days, this month, or sometime later? I'd re
Yonik Seeley wrote:
Lucene 2.1 has been a long time in coming, but I think we should plan
on making a release when the file format changes settle down.
Was there any kind of consensus of what 'soon' meant. Is it likely to be days,
this month, or sometime later? I'd really like to get lockles
e Wiki, there is a page there about how
> to contribute to Lucene.
>
> Otis (uh, so tempting to use another primate's name)
>
> - Original Message
> From: Tarzan <[EMAIL PROTECTED]>
> To: java-dev@lucene.apache.org
> Sent: Saturday, Januar
ROTECTED]>
To: java-dev@lucene.apache.org
Sent: Saturday, January 20, 2007 2:21:43 PM
Subject: Re: Lucene 2.1, soon
Hi There,
Congratulations to all Lucene developers for the upcoming release.
I am new to Lucene/Nutch but as far I have read about the two, I really find
it very inter
Hi There,
Congratulations to all Lucene developers for the upcoming release.
I am new to Lucene/Nutch but as far I have read about the two, I really find
it very interesting and wanna contribute in this project. But dont know
where to start...a friend suggested to write parsers for any fil
Hi There,
Congratulations to all Lucene developers for the upcoming release.
I am new to Lucene/Nutch but as far I have read about the two, I really find
it very interesting and wanna contribute in this project. But dont know
where to start...a friend suggested to write parsers for any fil
On 1/19/07, Michael McCandless <[EMAIL PROTECTED]> wrote:
I don't think we should hold up 2.1 for this. First, I'm not sure how
long it will take me to finish (I have a baby due in 23 days which is
making me very nervous!), and second I think we have alot of good stuff
already in the trunk to ma
Otis Gospodnetic wrote:
Hi,
Actually, I quite-like and agree with Marvin's suggestion. If NFS 4 indeed does work
well with Lucene, and NFS 3 does not, then I think it's reasonable to expect people to
get NFS 4 to make their Lucene apps work correctly with them. Maybe I got lost in this
thre
Chuck Williams wrote:
I need to support NFS and would not want to rely on the reader
refreshing in X minutes. Setting X too small risks a query failure and
setting X too large wastes disk space. X would need to be set for 100%
reader availability, implying a large value and a lot of disk space
Doron Cohen wrote:
Sounds good to me.
So it is IndexFileDeleter that can be used by applications to guarantee
"their" NFS-safe behavior, namely preventing premature files deletions.
Cool. We can probably sometimes write one such alternative, even in
contrib.
But, should enabling this way of ex
--- Original Message
From: Michael McCandless <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Thursday, January 18, 2007 5:24:16 PM
Subject: Re: Lucene 2.1, soon
Marvin Humphrey wrote:
>
> On Jan 17, 2007, at 1:16 PM, Michael McCandless wrote:
>
> The real problem
Sounds good to me.
So it is IndexFileDeleter that can be used by applications to guarantee
"their" NFS-safe behavior, namely preventing premature files deletions.
Cool. We can probably sometimes write one such alternative, even in
contrib.
But, should enabling this way of extending IndexFileDele
I need to support NFS and would not want to rely on the reader
refreshing in X minutes. Setting X too small risks a query failure and
setting X too large wastes disk space. X would need to be set for 100%
reader availability, implying a large value and a lot of disk space waste.
I like the idea
Doron Cohen wrote:
I am not happy with complicating the readers like this, conceptually
adding back commit locks (for deletion), this time with a keep-a-life
thread, and again making readers not read-only.
To my understanding the only remaining issue with NFS is: a reader
might get an IO excepti
On Jan 18, 2007, at 2:59 PM, Doron Cohen wrote:
To my understanding the only remaining issue with NFS is: a reader
might get an IO exception in case writer removed an old file that
the reader is using.
It is not a possible corruption that we try to solve, right?
For that I think it is not wor
On Jan 18, 2007, at 2:24 PM, Michael McCandless wrote:
I think we should decouple the deletion policy from commits. This way
developers could subclass and make their own deletion policy that
suits their application.
But your excellent work has brought us so close to just handling all
deleti
I am not happy with complicating the readers like this, conceptually
adding back commit locks (for deletion), this time with a keep-a-life
thread, and again making readers not read-only.
To my understanding the only remaining issue with NFS is: a reader
might get an IO exception in case writer rem
The touching doesn't have to be that timely.
If the indexed is configured to only keep old segments less than x
hours old, you just check if any of the timestamps are with x hours,
and if not you can delete the segments. So even if the reader is late
updating the timestamp - they would need
On Jan 18, 2007, at 2:17 PM, Michael McCandless wrote:
How about if each reader were assigned a unique ID (eg hostname) by
the application, and wrote a file ($ID.inuse or something) into the
index dir referencing the segments_N that it's currently using?
It would have to go in the old /tmp lo
Marvin Humphrey wrote:
On Jan 17, 2007, at 1:16 PM, Michael McCandless wrote:
This is the solution I have in mind for LUCENE-710: change the
IndexFileDeleter so that instead of always immediately deleting the
last commit when a new commit happens, allow some time before doing
so. This way rea
You would also have to add a requirement that readers touch the file
every N minutes, otherwise dead users will prevent cleanup
On Jan 18, 2007, at 4:17 PM, Michael McCandless wrote:
Marvin Humphrey wrote:
On Jan 18, 2007, at 1:58 PM, Chuck Williams wrote:
How about a direct solution with a
Marvin Humphrey wrote:
On Jan 18, 2007, at 1:58 PM, Chuck Williams wrote:
How about a direct solution with a reference count scheme?
Segments files could be reference-counted,
There would have to be a file where the refcounts are maintained. The
problem is that if an IndexReader crashes,
This won't work with multiple JVMs attached to the same Lucene
directory.
All JVMs need to vote as whether or not certain segments can be
deleted, since the others JVMS can't know this. How you do this...
On Jan 18, 2007, at 3:58 PM, Chuck Williams wrote:
How about a direct solution with
On Jan 18, 2007, at 1:58 PM, Chuck Williams wrote:
How about a direct solution with a reference count scheme?
Segments files could be reference-counted,
There would have to be a file where the refcounts are maintained.
The problem is that if an IndexReader crashes, it could orphan a
ref
How about a direct solution with a reference count scheme?
Segments files could be reference-counted, as well as individual
segments either directly, possibly by interning SegmentInfo instances,
or indirectly by reference counting all files via Directory.
The most recent checkpoint and snapshot w
I wrote:
I'd be cool with making it impossible to put an index on an NFS
volume prior to version 4.
Elaborating and clarifying...
IndexReader attempts to establish a read lock on the relevant
segments_N file. It doesn't bother to see whether the locking
attempt succeeds, though.
Index
On Jan 17, 2007, at 1:16 PM, Michael McCandless wrote:
This is the solution I have in mind for LUCENE-710: change the
IndexFileDeleter so that instead of always immediately deleting the
last commit when a new commit happens, allow some time before doing
so. This way readers have a chance to re
Marvin Humphrey wrote:
On Jan 17, 2007, at 3:42 AM, Grant Ingersoll wrote:
Also, I'm curious as to how many people use NFS in live systems.
KS has the same problems Lucene does, and it's a common enough complaint
that I've added an FAQ item. It's an important issue.
I agree it's importan
On Jan 17, 2007, at 3:42 AM, Grant Ingersoll wrote:
I think since we have already made some file format changes, we
should consider some of the others on the table, namely https://
issues.apache.org/jira/browse/LUCENE-510
which concerns proper UTF-8 storage. The big issue with this one
see
Grant Ingersoll wrote on 01/17/2007 01:42 AM:
> Also, I'm curious as to how many people use NFS in live systems.
>
I've got the requirement to support large indexes and collections of
indexes on NAS devices, which from linux pretty much means NFS or CIFS.
This doesn't seem unusual.
Chuck
-
I think since we have already made some file format changes, we
should consider some of the others on the table, namely https://
issues.apache.org/jira/browse/LUCENE-510
which concerns proper UTF-8 storage. The big issue with this one
seems to be performance (and the patch needs to be updated
Michael McCandless wrote:
+1 for releasing 2.1 soon.
I hope to get explicit commits (LUCENE-710) working, which has a tiny
file format change, and LUCENE-773 (deprecate FSDirectory.getDirectory
methods that take a create arg) completed soon, so we can get them
into 2.1, if possible.
Given the
after 2.1!
Mike
Otis Gospodnetic wrote:
Same here. As soon as the file format changes settle down.
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, January 16, 2007 12:26:43 PM
Subject: Re: Lucene 2.1, soon
+1
Was th
Same here. As soon as the file format changes settle down.
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, January 16, 2007 12:26:43 PM
Subject: Re: Lucene 2.1, soon
+1
Was thinking the same thing this morning
+1
Was thinking the same thing this morning. The changes.txt 2.1
section is getting quite long.
On Jan 16, 2007, at 12:16 PM, Yonik Seeley wrote:
Lucene 2.1 has been a long time in coming, but I think we should plan
on making a release when the file format changes settle down.
After that,
Lucene 2.1 has been a long time in coming, but I think we should plan
on making a release when the file format changes settle down.
After that, I think we should start making more frequent releases,
which should make make many people's lives easier by
1) give people something more recent to work
58 matches
Mail list logo
