Mailing List Archive

Alan,
Please don't be discouraged, in most cases the reason is the lack of
time. I am writing this from work :)
I will try looking at your code later on and committing it if all is
good with it.

Otis

--- Alan Weissman <aweissman@clientelligence.net> wrote:
> devs -
>
> Judging by the lack of response to my message yesterday
> containing some
> ideas for additions and changes I am assuming that there is no
> interest. As
> this was my first attempt at open source contribution, could someone
> explain
> why there is no interest in these types of changes?
>
> Thanks very much,
> Al
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

> Judging by the lack of response to my message yesterday containing some
> ideas for additions and changes I am assuming that there is no interest.

Unjustified leap to conclusion. There are dozens of other reasons why
you might not have gotten a response.

> As this was my first attempt at open source contribution, could
> someone explain why there is no interest in these types of changes?

Here are some reasons why you might not have gotten a response, even though
your suggestion may have been sensible.

1. In open-source projects, people generally respond only to issues
that interest them, either because its their thing, or because it
touches on a problem they are solving. For example, I try to respond
to anything having to do with the query parser, but generally ignore
stuff dealing with, say, hit scoring.

2. The level of urgency to fix something that's not "obviously"
broken in open-source projects varies with how much time participants
have at the moment. Most people on this list have jobs, and
open-source stuff is a fun diversion but doesn't usually grab our full
attention. So maybe you need to wait longer for a response, or wait
for a similar issue to crop up, or ask again at a later date.

3. We're sort of in a "release lockdown" mode now.

4. Maybe your suggestion didn't grab anyone's interest, not because
its not useful or valuable, just because it didn't. Every cause needs
a champion; this cause may not yet have one. It may or may not need
one.

Open-source projects are chaotic, but cool stuff does emerge from the
chaos. Don't be discouraged!


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

> From: Dmitry Serebrennikov [mailto:dmitrys@earthlink.net]
>
> I know at least in my case, I have a much more extensive list of stop
> words and they are simply read from a file into an array and
> then passed
> to the existing class. Would this approach work in your case?

I think that serious applications will usually need to define an Analyzer
class, or at least parameterize an existing class, rather than just use
something as-is off the shelf. They might want to analyze different fields
differently, or might want to use a particular stop list, or might care
about how particular acronyms are tokenized and normalized.

So we should not attempt to provide analyzers that make everyone happy: that
effort is destined to fail. Rather, we should attempt to provide tools to
make it easy to create lots of different, useful, analyzers.

I think the proposed StrictAnalyzer shows that the analyzer toolkit is good:
Alan was able to create the analyzer he needs with just a few lines of code,
mostly assembling existing bits and pieces. It would be simpler yet if he
was able to extend StandardAnalyzer, providing just a different stop list.

So the action item I see is that StandardAnalyzer should be made non-final.

We should not change the default stop lists in Lucene, since that would
break existing indexes when folks upgrade to a new version of Lucene. A
library of file-based stop lists is a good idea, though.

Doug

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

Hi Alan,

I know at least in my case, I have a much more extensive list of stop
words and they are simply read from a file into an array and then passed
to the existing class. Would this approach work in your case? It seemed
that adding a new class just to have a new set of default stop words was
not particularly required. It would probably prove to be more confusing
than anything else. However, there might be an argument for changing the
default set that is already in the existing class. I had not checked,
but if the new set is much better than the old one, I'd +1 it.

-dmitry

Alan Weissman wrote:

>devs -
>
> Judging by the lack of response to my message yesterday containing some
>ideas for additions and changes I am assuming that there is no interest. As
>this was my first attempt at open source contribution, could someone explain
>why there is no interest in these types of changes?
>
>Thanks very much,
>Al
>
>--
>To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
>




--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>