[
https://issues.apache.org/jira/browse/LUCENE-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002877#comment-13002877
]
Mark Miller commented on LUCENE-2939:
-------------------------------------
{quote}Moving
an issue out, stating that an issue won't make the RC,
is fair game. These are the normal "tools" of the RM...{quote}
Not in my experience.
Regardless, I'm not sure this is the same as changing a JIRA issue right after
someone else changes it with no discussion and apparent lack of understanding
of the issue. That's a statement if you ask me. If you look at how the culture
of Lucene has worked, this is unusual - and I'll push to make it remain so.
bq. Putting pressure is precisely what Robert has done here (and onSOLR-2390)?
SOLR-2390 was this issue - this patch spans lucene and solr and covers both of
them. This issue was still marked 3.1 and we where discussing it when this
happened with SOLR-2390 - this is how I know little thought went into shoving
it out - SOLR-2390 should be in lock step with this issue. It's not a new or
another issue. It's just where I am tracking this from a Solr user bug
perspective - it's easier to have one patch.
{quote}
My point is, we all must expect/allow/not-get-upset-about this
"pressure" from the RM – it comes with the territory, and it's the
RM's right to be very aggressive in order to get the release done.
{quote}
Depends - I've seen a lot of RM's before - and I have been one. Personally I've
never seen things done this way. Nor do I think it was necessary. We would have
come to the same conclusion in either case. The history and culture of Lucene
has been to not be forceful in JIRA - that's something I'll argue to maintain.
{quote}
We gotta remove the barriers to doing releases around here, not add to
them.{quote}
Release at all costs is just not an excuse IMO. We release as often as someone
is willing to put in the somewhat massive effort really.
bq. In fact, we should scrutinize our scary ReleaseTodo and pare it
back to the bare minimum... it's gotta become a push button process.
I think we all agree with that. I'm still not aboard with the scary RM theory.
> Highlighter should try and use maxDocCharsToAnalyze in
> WeightedSpanTermExtractor when adding a new field to MemoryIndex as well as
> when using CachingTokenStream
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2939
> URL: https://issues.apache.org/jira/browse/LUCENE-2939
> Project: Lucene - Java
> Issue Type: Bug
> Components: contrib/highlighter
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Minor
> Fix For: 3.1.1, 3.2, 4.0
>
> Attachments: LUCENE-2939.patch, LUCENE-2939.patch, LUCENE-2939.patch
>
>
> huge documents can be drastically slower than need be because the entire
> field is added to the memory index
> this cost can be greatly reduced in many cases if we try and respect
> maxDocCharsToAnalyze
> things can be improved even further by respecting this setting with
> CachingTokenStream
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
