Grant Ingersoll wrote:
I'd _suggest_ a few other things beyond just code commits, however:
+1 for all these.
Finally, six months or so does sound like the right time frame.
So we can consider this fair warning: if there have only been a few
token commits, and there isn't activity consisten
+1. I don't see any point in rushing it either, but I don't feel like
we are, other than the sense that some decision needs to be made based
on this thread. Like I said before, this conversation isn't news to
those who are involved. I'm totally fine w/ giving the benefit of the
doubt, I
On Mon, Mar 09, 2009 at 03:06:45PM -0700, Doug Cutting wrote:
> Marvin, do you expect you'll be actively committing code
> to Lucy over the next six months?
Yes. I can commit Boilerplater and its support classes.
The general design of Boilerplater was hashed out by myself and Dave Balmain.
Al
Grant Ingersoll wrote:
Therefore, it is with some hesitation that I suggest we mothball Lucy.
When committers are inactive for a year, we ask them if they'd like to
be made emeritus. Usually they either don't respond or they say yes.
If they say "no" we give them the benefit of the doubt for
Hoss:
> The fundemental issue is really wether Lucy, as a project, is "alive".
There is one extremely active participant, and as this thread attests, there
is both a small community and demand for the product. Futhermore, the work
that is being done to move Lucy forward is benefitting Java Lucen
Jukka Zitting:
> Try to look at our end of the telescope
I understand the metric you are applying, and I understand and support the
Apache community activity threshold test. It is clear to me why this audit
has been triggered, and that by pursuing the matter the members of the PMC are
acting in
At this point, I'd recommend running with a memory profiler, eg
YourKit, and posting the resulting output.
With norms only on one field, no deletions, and no field sorting, I
can't see why you're running out of memory.
If you take Hibernate out of the picture, and simply open an
IndexSe
Release 2.4.1 of Lucene is now available.
This release fixes bugs from 2.4.0, including one data loss bug where
in certain situations binary fields would be truncated to 0 bytes.
2.4.1 has no new features, nor API changes or changes to file formats,
so it's fully compatible with 2.4.0.
See chang
luc...@digiatlas.org wrote:
Thanks Michael,
There is no sorting on the result (adding a sort causes OOM well before
the point it runs out for the default).
There are no deleted docs - the index was created from a set of docs and
no adds or deletes have taken place.
Memory isn't being consu
Thanks Michael,
There is no sorting on the result (adding a sort causes OOM well
before the point it runs out for the default).
There are no deleted docs - the index was created from a set of docs
and no adds or deletes have taken place.
Memory isn't being consumed elsewhere in the system
10 matches
Mail list logo
