Re: Lucene/Solr 6.0.0 Release Branch

[david.w.smi...@gmail.com]

I just want to clarify you(Nick) / our expectations about this release
branch.  It seems, based on issues I've seen like LUCENE-7072, that we can
commit to the release branch without your permission as RM.  If this is
true, then I presume the tacit approval is okay so long as it's not a new
feature.  Right?

On Wed, Feb 24, 2016 at 3:23 PM Nicholas Knize  wrote:

> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
> keep the ball moving and volunteer as the 6.0.0 RM.
>
> If there are no objections my plan is to cut branch_6_0 early next week -
> Mon or Tues. Please mark blocker issues accordingly and/or let me know if
> there are any commits needed before cutting the branch.
>
> - Nick
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Copyrights

[david.w.smi...@gmail.com]

I'll send a note to that Apache list; thanks for the reference.

On Tue, Mar 1, 2016 at 4:49 PM Mike Drob <md...@apache.org> wrote:

> I would check with legal-discuss@a.o to be sure, but here is my
> understanding of relevant ASF policies:
>
> All work done and contributed by an individual is bound by the terms of
> your ICLA. You retain the copyright ownership under ASLv2, but have granted
> the ASF (an irrevocable?) permission and license to use your work.
>
> If the work is copyright assigned to a different organization, then I
> believe it has to be brought in as a 3rd party work. It can retain the
> original headers, as long as the terms as compatible, and needs to be
> called out in NOTICE file like you alluded to.
>
> Dev-for-hire work happens pretty regularly in today's world; I don't think
> anybody is under the illusion that Lucene is built solely by a group of
> hobbyists. CCLAs cover most of the cases where the funding organization is
> willing to forgo copyright ownership, but that doesn't sound like the case
> here.
>
> I'm not sure what happens if a different person comes in later and finds a
> bug and makes changes to those files. Presumably we're fine, but some
> people might feel a little strange assigning copyright back to a unknown
> company instead of licensing use to the ASF.
>
> Mike
>
> On Tue, Mar 1, 2016 at 3:19 PM, david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
>> I'm considering doing some enhancements to Lucene/Solr on behalf of
>> another organization/entity who wants me to include copyright statements to
>> them.  Same ASLv2 license.  This is no big deal; right?  I see we've
>> already got some source files with non-ASF copyright licenses (e.g.
>> Automata.java and others), and I see we have NOTICE files referencing it
>> too.  I also see some special support in common-build.xml to detect it.
>>
>> ~ David
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Copyrights

[david.w.smi...@gmail.com]

I'm considering doing some enhancements to Lucene/Solr on behalf of another
organization/entity who wants me to include copyright statements to them.
Same ASLv2 license.  This is no big deal; right?  I see we've already got
some source files with non-ASF copyright licenses (e.g. Automata.java and
others), and I see we have NOTICE files referencing it too.  I also see
some special support in common-build.xml to detect it.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Master branch and java version

[david.w.smi...@gmail.com]

Me too; minutes after your notice Alan.  Thanks for the FYI.

On Tue, Mar 1, 2016 at 5:18 AM Varun Thacker 
wrote:

> I also ran into the same problem. I was using 1.8.0_31 . Upgrading worked
> though.
>
> On Tue, Mar 1, 2016 at 3:19 AM, Alan Woodward  wrote:
>
>> common.compile-core:
>> [javac] Compiling 1 source file to
>> /Users/woody/asf/lucene-solr-trunk/lucene/build/suggest/classes/java
>> [javac]
>> /Users/woody/asf/lucene-solr-trunk/lucene/suggest/src/java/org/apache/lucene/search/suggest/tst/TSTLookup.java:79:
>> error: cannot assign a value to final variable aStop
>> [javac]   aStop = aUpto + a.length;
>> [javac]   ^
>> [javac]
>> /Users/woody/asf/lucene-solr-trunk/lucene/suggest/src/java/org/apache/lucene/search/suggest/tst/TSTLookup.java:81:
>> error: cannot assign a value to final variable aStop
>> [javac]   aStop = aUpto + b.length;
>> [javac]   ^
>> [javac] 2 errors
>>
>> Compiles under 1.8.0_74, gives this error for 1.8.0_25
>>
>>
>> On 29 Feb 2016, at 21:38, Uwe Schindler wrote:
>>
>> Can you post the error? I touched that code yesterday. Maybe I broke
>> that. It would still be good to fix this.
>>
>> Uwe
>>
>> Am 29. Februar 2016 21:08:50 MEZ, schrieb Alan Woodward > >:
>>>
>>> Just in case anybody else out there runs into this, I was having
>>> problems compiling master earlier using Java 1.8.0_25, due to the compiler
>>> not liking an immediate assignment to a final variable in TSTLookup.java.
>>> Upgrading to 1.8.0_74 made the problem go away.
>>>
>>>
>>>
>> --
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, 28213 Bremen
>> http://www.thetaphi.de
>>
>>
>>
>
>
> --
>
>
> Regards,
> Varun Thacker
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 6.0.0 Release Branch

[david.w.smi...@gmail.com]

I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little
spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move
things around / rename.  But I don't mind doing an extra cherry pick in the
end if you want to go create the branch without waiting.  So I don't know
if you want to call that a blocker or not.

Also, FYI there's a feature LUCENE-5735
(NumberRangePrefixTreeStrategy.calcFacets) that I committed to master (but
not 5x) over a year ago but didn't quite close the issue.  I had found a
bug or two but then lost the time to finish it.   I'd rather remove this
feature from the 6x branch after you create the branch.  When I get more
time (very likely this year) I can resolve the lingering bugs and get it
into whatever 6.x release comes along then.  So nothing for you to do here
but wanted to let you know.

Hey thanks for pitching in to do the release.

~ David

On Wed, Feb 24, 2016 at 11:09 PM Nicholas Knize  wrote:

> Thanks Uwe!  Indeed we need branch_6x (and master versions changed) first.
> I'll plan to get that done Monday and/or Tuesday. Let me know if there are
> any blockers and I'll send a note to the list before I create the branch.
>
> - Nick
>
>
> On Wednesday, February 24, 2016, Uwe Schindler  wrote:
>
>> Hi Nicholas,
>>
>>
>>
>> before we start a branch_6_0 we should do the following:
>>
>>
>>
>> -  Start branch_6x as “new stable branch”
>>
>> -  Update version numbers in “master” to 7.0
>>
>>
>>
>> This should be done maybe early next week and then after a while that
>> things settle (also the Jenkins Jobs for branch_6x are set up), we can
>> proceed with a gap:
>>
>> -  Cut branch_6_0
>>
>> -  Update version numbers in “branch_6x” to 6.1
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Nicholas Knize [mailto:nkn...@gmail.com]
>> *Sent:* Wednesday, February 24, 2016 9:23 PM
>> *To:* Lucene/Solr dev 
>> *Subject:* Lucene/Solr 6.0.0 Release Branch
>>
>>
>>
>> With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to
>> keep the ball moving and volunteer as the 6.0.0 RM.
>>
>>
>>
>> If there are no objections my plan is to cut branch_6_0 early next week -
>> Mon or Tues. Please mark blocker issues accordingly and/or let me know if
>> there are any commits needed before cutting the branch.
>>
>>
>>
>> - Nick
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: ZK Connection Failure leads to stale data

[david.w.smi...@gmail.com]

Both sound very good to me, Dennis. Thanks.
On Wed, Feb 10, 2016 at 11:55 AM Dennis Gove  wrote:

> Just wanted to take a moment to get anyone's thoughts on the following
> issues
>
> https://issues.apache.org/jira/browse/SOLR-8599
> https://issues.apache.org/jira/browse/SOLR-8666
>
> The originating problem occurred due to a DNS failure that caused some
> nodes in a cloud setup to fail to connect to zookeeper. Those nodes were
> running but were not participating in the cloud with the other nodes. The
> disconnected nodes would respond to queries with stale data, though they
> would reject injest requests.
>
> Ticket https://issues.apache.org/jira/browse/SOLR-8599 contains a patch
> which ensures that if a connection to zookeeper fails to be made it will be
> retried. Previously the failure wasn't leading to a retry so the node would
> just run and be disconnect until the node itself was restarted.
>
> Ticket https://issues.apache.org/jira/browse/SOLR-8666 contains a patch
> which will result in additional information returned to the client when a
> node may be returning stale data due to not being connected to zookeeper.
> The intent was to not change current behavior but allow the client to know
> that something might be wrong. In situations where the collection is not
> being updated the data may not be stale so it wouldn't matter if the node
> is disconnected from zookeeper but in situations where the collection is
> being updated then the data may be stale. The headers of the response will
> now contain an entry to indicate this. Also, adds a header to the ping
> response to also provide notification if the node is disconnected from
> zookeeper.
>
> I think the approach these patches take are good but wanted to get others'
> thoughts and perhaps I'm missing a case where these might cause a problem.
>
> Thanks - Dennis
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+104) - Build # 15822 - Still Failing!

[david.w.smi...@gmail.com]

LOL

On Tue, Feb 9, 2016 at 4:43 AM Uwe Schindler  wrote:

> LOL. If compact string wouldn't have been disabled, I would say: Compact
> String comprumpted(TM) the version :-)
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Robert Muir [mailto:rcm...@gmail.com]
> > Sent: Tuesday, February 09, 2016 4:00 AM
> > To: dev@lucene.apache.org
> > Subject: Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+104) -
> > Build # 15822 - Still Failing!
> >
> > best jvm crash ever.
> >
> > On Mon, Feb 8, 2016 at 9:54 PM, Policeman Jenkins Server
> >  wrote:
> > >[junit4] >>> JVM J2 emitted unexpected output (verbatim) 
> > >[junit4] #
> > >[junit4] # A fatal error has been detected by the Java Runtime
> > Environment:
> > >[junit4] #
> > >[junit4] #  SIGSEGV (0xb) at pc=0x89c03155, pid=14255, tid=14333
> > >[junit4] #
> > >[junit4] # JRE version: ˆ„K÷ +¡àø+¡à  (9.0+104) (build )
> > >[junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+104-2016-02-03-
> > 214936.javare.4385.nc, mixed mode, tiered, concurrent mark sweep gc,
> > linux-x86)
> > >[junit4] # Problematic frame:
> > >[junit4] # C  0x89c03155
> > >[junit4] #
> > >[junit4] # No core dump will be written. Core dumps have been
> disabled.
> > To enable core dumping, try "ulimit -c unlimited" before starting Java
> again
> > >[junit4] #
> > >[junit4] # An error report file with more information is saved as:
> > >[junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-
> > Linux/lucene/build/codecs/test/J2/hs_err_pid14255.log
> > >[junit4] [thread 15849 also had an error]
> > >[junit4] [thread 14331 also had an error]
> > >[junit4] [thread 14332 also had an error]
> > >[junit4]
> > >[junit4] [error occurred during error reporting , id 0xb]
> > >[junit4]
> > >[junit4] #
> > >[junit4] # If you would like to submit a bug report, please visit:
> > >[junit4] #   http://bugreport.java.com/bugreport/crash.jsp
> > >[junit4] #
> > >[junit4] <<< JVM J2: EOF 
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: What is the story for AdminUI for 5.x vs 6.0?

[david.w.smi...@gmail.com]

+1 to Erick's sentiment.  6.0 new UI.

On Tue, Feb 9, 2016 at 10:02 PM Erick Erickson 
wrote:

> My vote is +1 for 6.0 defaulting to the new admin UI. Whatever remains
> undone, it's time to move to the new version and fix whatever crops
> up.
>
> Maybe just leave a link in to the old UI, but definitely default to the
> new one.
>
> FWIW,
> Erick
>
> On Tue, Feb 9, 2016 at 2:58 PM, Alexandre Rafalovitch
>  wrote:
> > Since we are discussing the next release, what is the plan with
> > old/new Admin UI? Is the plan that the new UI will still be behind the
> > URL switch in the last release of the 5.x line?
> >
> > My thought was that we do the new UI for a little bit then switch over
> > and kill the old one. With that transition happening within a couple
> > of minor versions. But I do not see that discussion and it seems that
> > perhaps even the last release on the 5.x line will still have dual UI.
> >
> > And what about for 6?
> >
> > Regards,
> >Alex.
> > 
> > Newsletter and resources for Solr beginners and intermediates:
> > http://www.solr-start.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

+1 I'll do it.

On Wed, Feb 3, 2016 at 3:29 PM Mark Miller <markrmil...@gmail.com> wrote:

> Yeah man, ugly noise. I think we should open a JIRA to discuss with INFRA
> anyway. At a minimum, we should be able to specify which main branches we
> care about. Creating noise for everyone's random work branches is crazy.
>
> - Mark
>
> On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
> david.w.smi...@gmail.com> wrote:
>
>> Ok thanks.  It's too bad it's not going to be changed.  IMO, I don't
>> these extra commit notifications are helpful beyond the original appearance
>> of a given commit.
>> ~ David
>>
>> On Tue, Feb 2, 2016 at 10:52 PM Ryan Ernst <r...@iernst.net> wrote:
>>
>>> By the way, I meant I attended a talk *about git at apache*
>>> On Feb 2, 2016 19:50, "Ryan Ernst" <r...@iernst.net> wrote:
>>>
>>>> This is expected, as merging in the commit to a branch does create a
>>>> new commit for that branch (or rather it is then visible in the history of
>>>> that branch while before it was not).
>>>>
>>>> Two years ago at ApacheCon I attended a talk by David Nalley. This
>>>> issue was brought up, and I spoke a little with him afterwards about it. At
>>>> that time, infra had no plans to change anything about how the alerts
>>>> worked.
>>>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>>>> david.w.smi...@gmail.com> wrote:
>>>>
>>>>> I noticed something different today about the bot that posts git
>>>>> commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
>>>>> super
>>>>> simple with 2 commits, one for master and one for branch_5x.  I promptly
>>>>> saw a comment appear after each commit.  But then today, to my surprise, I
>>>>> got notified of a new comment from this bot on this issue that was not
>>>>> triggered by an action on my part.:
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>>>>
>>>>> Notice it's for a branch master-solr-8621.  Christine apparently
>>>>> created the branch, did some work, and then brought it up to date with
>>>>> master.  That must have caused this commit.  Does anyone know if the ASF 
>>>>> or
>>>>> whoever knows about this and perhaps is working to fix it?  I'm sure the
>>>>> coding of the bot could be improved to account for this situation; there
>>>>> seems to be enough metadata to differentiate.
>>>>>
>>>>> ~ David
>>>>> --
>>>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>>> http://www.solrenterprisesearchserver.com
>>>>>
>>>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
> - Mark
> about.me/markrmiller
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

https://issues.apache.org/jira/browse/INFRA-11198
I don't think this has to do with some branches being more significant than
others.  I think it has to do with the fact that the commit has occurred
multiple times (same hash); we just care about the first chronologically.
Any way; further discussion of our theories on how to fix it should happen
on the issue.

On Wed, Feb 3, 2016 at 3:42 PM david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> +1 I'll do it.
>
> On Wed, Feb 3, 2016 at 3:29 PM Mark Miller <markrmil...@gmail.com> wrote:
>
>> Yeah man, ugly noise. I think we should open a JIRA to discuss with INFRA
>> anyway. At a minimum, we should be able to specify which main branches we
>> care about. Creating noise for everyone's random work branches is crazy.
>>
>> - Mark
>>
>> On Wed, Feb 3, 2016 at 3:09 PM david.w.smi...@gmail.com <
>> david.w.smi...@gmail.com> wrote:
>>
>>> Ok thanks.  It's too bad it's not going to be changed.  IMO, I don't
>>> these extra commit notifications are helpful beyond the original appearance
>>> of a given commit.
>>> ~ David
>>>
>>> On Tue, Feb 2, 2016 at 10:52 PM Ryan Ernst <r...@iernst.net> wrote:
>>>
>>>> By the way, I meant I attended a talk *about git at apache*
>>>> On Feb 2, 2016 19:50, "Ryan Ernst" <r...@iernst.net> wrote:
>>>>
>>>>> This is expected, as merging in the commit to a branch does create a
>>>>> new commit for that branch (or rather it is then visible in the history of
>>>>> that branch while before it was not).
>>>>>
>>>>> Two years ago at ApacheCon I attended a talk by David Nalley. This
>>>>> issue was brought up, and I spoke a little with him afterwards about it. 
>>>>> At
>>>>> that time, infra had no plans to change anything about how the alerts
>>>>> worked.
>>>>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>>>>> david.w.smi...@gmail.com> wrote:
>>>>>
>>>>>> I noticed something different today about the bot that posts git
>>>>>> commits to applicable JIRA issues.  I recently worked on SOLR-7968 -- 
>>>>>> super
>>>>>> simple with 2 commits, one for master and one for branch_5x.  I promptly
>>>>>> saw a comment appear after each commit.  But then today, to my surprise, 
>>>>>> I
>>>>>> got notified of a new comment from this bot on this issue that was not
>>>>>> triggered by an action on my part.:
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>>>>>
>>>>>> Notice it's for a branch master-solr-8621.  Christine apparently
>>>>>> created the branch, did some work, and then brought it up to date with
>>>>>> master.  That must have caused this commit.  Does anyone know if the ASF 
>>>>>> or
>>>>>> whoever knows about this and perhaps is working to fix it?  I'm sure the
>>>>>> coding of the bot could be improved to account for this situation; there
>>>>>> seems to be enough metadata to differentiate.
>>>>>>
>>>>>> ~ David
>>>>>> --
>>>>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>>>> http://www.solrenterprisesearchserver.com
>>>>>>
>>>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Naming branches so that life is easier

[david.w.smi...@gmail.com]

Establishing conventions and adhering to them would be good.

Some observations I have with your example:  you suggested a hypothetical
branch named "dweiss/jira3826".  IMO that branch name isn't a great name
because it is ambiguous with respect to it being for Lucene or Solr.  Most
of our branches in the past have been in the format for the JIRA issue;
sometimes lowercased or sometimes with an underscore.  It'd be nice to
standardize that.  I propose the form "solr_3626" but I care little and
only would like to see something adhered to.  Incorporating a branch for a
JIRA issue with someone's user id is I think questionable, but I have no
strong opinion.  I think we should generally do it or not do it.

~ David

On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss  wrote:

> Hey folks. Just noticed new branches are being pushed to the Apache
> repository. Having digested SVN's branches I'd like to suggest a
> naming convention for branches so that they appear more palatable. For
> example:
>
> $ git branch -r
>   origin/HEAD -> origin/master
>   origin/apiv2
>   origin/branch_3x
>   origin/branch_4x
>   origin/branch_5x
>   origin/lucene-6835
>   origin/master
>   origin/master-solr-8621
>
>
> The labels (branches and tags) in git can be pseudo-hierarchical. It
> is therefore nice to see more "semantic" branches, like:
>
> origin/jira/solr8621
> origin/dweiss/fooBarExperiment
> origin/staging/lucene-solr-x.y.z
>
> I don't think it's realistic to enforce any rigid convention, but I'm
> sure you get the gist.
>
> These branches are no different to regular, they're just labeled with a
> slash:
>
> # checkout a given branch/ commit (master here) and create a branch from
> it.
> git checkout master -b dweiss/jira3826
> # push this branch to origin and make it track changes on the origin's
> pushed branch.
> git push origin HEAD -u
>
> This is a suggestion only, not a requirement, but I'm sure you'll grow
> to like it. The upside is that everyone then knows whether it's your
> experimental stuff, something still being worked on, etc.
>
> Dawid
>
> P.S. There is always a way to "rename" a branch -- it is a label
> attached to a commit after all -- I'll leave these commands for you to
> digest:
>
> git checkout master-solr-8621 -b jira/solr8621-master
> git push origin HEAD -u
> # remove local branch
> git branch -D master-solr-8621
> # remove remote branch (use *only* on the stuff you actually control
> and merged back or abandoned)
> git push origin :master-solr-8621
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

Right; I can't imagine any of us actually trying to merge master to
branch_whatever.  We cherry-pick.  Nobody has dissented on that to my
knowledge.

~ David

On Wed, Feb 3, 2016 at 8:19 PM Ryan Ernst  wrote:

> > Are you sure *all* back porting will be done by cherry picking?
>
> Using merge commits for backporting would require resolving all
> differences between master and the stable branch. From what I've seen,
> using merge commits between two long lived branches usually happens in
> other projects by forward porting, not backporting. I thought this was
> pointed out (that cherry picking is really the only way to backport) in an
> earlier git thread, but I could be wrong.
>
> On Wed, Feb 3, 2016 at 5:06 PM, Chris Hostetter 
> wrote:
>
>>
>> : > unless i'm missing something, only getting email/jira
>> : > notifications the first time a specific commit was seen would mean
>> that
>> : > when backporting from master to 5x (or 6x down the road) there would
>> be no
>> : > tracking email/comment ... which would make it much harder to know
>> when
>> : > things were backported.
>>
>> : I don't think that is true, since backporting would be done with
>> : cherry-pick, which actually creates a new commit (and thus a different
>> : hash). This issue is about the *same* hash appearing on multiple
>> branches
>> : through merge commits.
>>
>> Are you sure *all* back porting will be done by cherry picking?
>>
>> I don't rememebr seeing any clear cut concensus on that to make me
>> comfortable with taking it for granted in the context of this discussion.
>>
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: git commits on JIRA issues;

[david.w.smi...@gmail.com]

Ok thanks.  It's too bad it's not going to be changed.  IMO, I don't these
extra commit notifications are helpful beyond the original appearance of a
given commit.
~ David

On Tue, Feb 2, 2016 at 10:52 PM Ryan Ernst <r...@iernst.net> wrote:

> By the way, I meant I attended a talk *about git at apache*
> On Feb 2, 2016 19:50, "Ryan Ernst" <r...@iernst.net> wrote:
>
>> This is expected, as merging in the commit to a branch does create a new
>> commit for that branch (or rather it is then visible in the history of that
>> branch while before it was not).
>>
>> Two years ago at ApacheCon I attended a talk by David Nalley. This issue
>> was brought up, and I spoke a little with him afterwards about it. At that
>> time, infra had no plans to change anything about how the alerts worked.
>> On Feb 2, 2016 19:43, "david.w.smi...@gmail.com" <
>> david.w.smi...@gmail.com> wrote:
>>
>>> I noticed something different today about the bot that posts git commits
>>> to applicable JIRA issues.  I recently worked on SOLR-7968 -- super simple
>>> with 2 commits, one for master and one for branch_5x.  I promptly saw a
>>> comment appear after each commit.  But then today, to my surprise, I got
>>> notified of a new comment from this bot on this issue that was not
>>> triggered by an action on my part.:
>>>
>>>
>>> https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982
>>>
>>> Notice it's for a branch master-solr-8621.  Christine apparently created
>>> the branch, did some work, and then brought it up to date with master.
>>> That must have caused this commit.  Does anyone know if the ASF or whoever
>>> knows about this and perhaps is working to fix it?  I'm sure the coding of
>>> the bot could be improved to account for this situation; there seems to be
>>> enough metadata to differentiate.
>>>
>>> ~ David
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

git commits on JIRA issues;

[david.w.smi...@gmail.com]

I noticed something different today about the bot that posts git commits to
applicable JIRA issues.  I recently worked on SOLR-7968 -- super simple
with 2 commits, one for master and one for branch_5x.  I promptly saw a
comment appear after each commit.  But then today, to my surprise, I got
notified of a new comment from this bot on this issue that was not
triggered by an action on my part.:

https://issues.apache.org/jira/browse/SOLR-7968?focusedCommentId=15127982=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15127982

Notice it's for a branch master-solr-8621.  Christine apparently created
the branch, did some work, and then brought it up to date with master.
That must have caused this commit.  Does anyone know if the ASF or whoever
knows about this and perhaps is working to fix it?  I'm sure the coding of
the bot could be improved to account for this situation; there seems to be
enough metadata to differentiate.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Updating whoweare page

[david.w.smi...@gmail.com]

Thanks for this cleanup Jan.

I'm not sure how useful the date of joining is.  It's not a proxy for who
is active, which is more useful but also hard to capture.  Perhaps we could
link to BlackDuck's "OpenHub" (formerly oholoh.net or something like that;
it was a terrible name I always typo'ed)
https://www.openhub.net/p/solr/contributors/summary
https://www.openhub.net/p/lucene/contributors/summary
Note: I went there and realized they weren't aware of our move to GitHub.
I'm in the process of updating this info for Lucene and Solr on OpenHub.
So depending on when you view this and how long it takes them, what you see
could be incomplete.

Cheers,
~ David

On Fri, Jan 29, 2016 at 8:49 AM Shawn Heisey  wrote:

> On 1/29/2016 3:11 AM, Jan Høydahl wrote:
> > The page https://lucene.apache.org/whoweare.html used to be sorted on
> last name. However somewhere along the way things got messed up and new
> committers started adding themselves to the end of the list.
> >
> > I have re-sorted the list, and want your consent to publish the changes.
> Please review the staging site
> http://lucene.staging.apache.org/whoweare.html as well as the diff:
> https://dl.dropboxusercontent.com/u/20080302/whoweare.patch and verify
> that I have not messed up anything :-)
>
> There is one thing the current sort gives somebody who looks at the page
> -- an idea of who's new and who isn't. :)
>
> I have no strong objection to your proposal.  If it had been sorted when
> I added my name, I would have put it in the middle of the list instead
> of the end and thought nothing of it.
>
> I do wonder if maybe there's a record of the date that each committer
> joined, and whether it would be appropriate to include that information?
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: "newdev" Label Reminder

[david.w.smi...@gmail.com]

Thanks for the reminder Jason; I'll keep this in mind.  I'll create an
issue today I have in mind as appropriate for newdev :-)

On Thu, Jan 28, 2016 at 8:56 AM Jason Gerlowski 
wrote:

> Hi all,
>
> Just wanted to remind everyone of the "newdev" label, which is used to
> identify JIRA tasks appropriate for new/inexperienced Solr
> contributors.
>
> I was reminded of this after a conversation on SOLR-7981, when a
> prospective contributor shared a bit of frustration with the "newdev"
> list.  A quick glance at the list confirms why- most of its entries
> are from back in the SOLR-2XXX days (roughly 2010, 2011).  Many of
> these stories are either invalid, already-closed, or have stalled out
> for various reasons.
>
> The list *is* helpful (I know I benefitted from having it when I
> started working with SOLR a few months back), but it could use a bit
> of an update.  So I wanted to start this email thread as a way to
> remind/ask others to keep an eye out for self-contained, easier tasks
> that might be ideal for new developers.
>
> Thanks to all for hearing me out.
>
> http://s.apache.org/newdevlucenesolr
>
> Jason
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Ongoing index maintenance

[david.w.smi...@gmail.com]

Hi,

I don't think the Lucene layer is lacking in this regard.  Higher up the
stack in Solr (or ES), it's conceivable one could do some of the functions
you propose by adding by wrapping the reader (FilteredReader) that then
does what you want -- removing a field, renaming a field, aliasing a field,
possibly even adding the appearance of docValues by uninverting
(UninvertingReader).  Though anything to do with altering the analysis
chain on tokenized text, other than removing it, isn't an option, short of
some long-running task to do that re-analysis and augment the index somehow
(ParallelReader perhaps).

~ David

On Tue, Jan 26, 2016 at 8:45 PM Erick Erickson 
wrote:

> Throwing this out for discussion, its roots are that a client raised
> the question referred to here:
> https://issues.apache.org/jira/browse/LUCENE-1761
>
> That got me to thinking. We often recommend "just reindex" as a
> solution for numbers of issues. As Lucene is used on ever-larger
> collections of documents, reindexing can get more and more
> painful/unlikely and perhaps impossible. I'd like to discuss a bit
> whether Lucene has evolved new capabilities that we might want to use
> to support some (limited) "index maintenance" tasks.
>
> So let's postulate an "index maintenance" utility. Checkindex is
> already one diagnostic/maintenance task. IndexUpgrade could be thought
> of as a maintenance task too.
>
> Would it be possible (and worth the effort) to add other kinds of
> tasks, Especially with DocValues type fields? Some kinds of functions
> that come to mind:
> > remove field X from the corpus
> > Add field Y to every doc in the corpus with default value Z (maybe
> docValues only?)
> > ???
>
> Possibly some of the kinds of maintenance tasks that people dream up
> could be restricted to, say, docValues fields or primitive types. I
> don't see how it would work to delete a text-based field and re-add it
> with a different analysis chain, that's just crazy.
>
> But Solr/Lucene/ES are being more and more used in analytics functions
> rather than straight text search. I continually have to check my
> assumptions at the client's door about what the purpose of "search"
> is. I've seen many situations where the search is simple keyword
> matching, the value the client sees is being able to perform analytics
> on the results of those simple searches.
>
> Now, I'll be the first to admit that my knowledge of Lucene internals
> (and that's where the bulk of the work would be no doubt) is scanty
> and it may be that this is all totally impossible. It may also be that
> there are few enough use-cases for this kind of thing that the effort
> is a poor ROI.
>
> That said, we've been handing out advice of "just reindex" for a long
> while. Reindexing may just not be possible so I wanted to kick off a
> discussion here.
>
> Thoughts?
> Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: highlight on phrase search not working

[david.w.smi...@gmail.com]

Hi Zaccheo,
In general this developer community lives on JIRA.  Since you have
questions pertaining to that JIRA issue then simply put those comments
there.  I already commented on that issue a few minutes ago.  The general
info for "how to contribute" (to Solr; largely applies to Lucene too) is
first to go to the Solr website, then click the Community link, then you'll
see a "How to Contribute" section:
http://lucene.apache.org/solr/resources.html#community  which in turn links
to: http://wiki.apache.org/solr/HowToContribute
Thanks for wanting to lend a hand.
~ David

On Tue, Jan 26, 2016 at 6:25 AM Zaccheo Bagnati  wrote:

> Hi all,
> we're experiencing some problems in highlighting terms of a phrase search.
> I have already created a jira issue (
> https://issues.apache.org/jira/browse/SOLR-8537) where the problem is
> explained in detail with minimal dataset to reproduce. Now I'm realizing
> that probably that wasn't the right approach: maybe I should have asked
> here before...
> However. My question is: do you have any advice on how can I help on that?
> I'm quite a newbye as a java programmer (even if I've been a programmer for
> many years in other languages) but maybe I can try to write a junit test
> for that, if it helps.
> Thank you
> Bye
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: reviews.apache.org / GIT migration

[david.w.smi...@gmail.com]

+1; I can't see how anyone would object to adding/retaining support for the
tool.  Nobody is forced to use it.

I'm curious of the move to Git allows for possibly better options.  I've
heard good things about Gerrit but I've never tried it.  I have mixed
feelings of my experience with Reviewboard, but *anything* beats reviewing
big patch files!

Mark, Greg what do you guys think?  I recall you two used it too.

On Tue, Jan 26, 2016 at 10:33 AM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Looks like https://issues.apache.org/jira/browse/INFRA-7630 set up the
> original/existing review board. If there are no objections or existing
> ticket then I will raise a similar ticket towards the end of this week.
>
> Christine
>
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: Jan 26 2016 15:18:22
>
> Hello.
>
> Having not used it before, I'd like to try out reviews.apache.org (even
> though it's only been used a few times for the project in the past based on
> the https://reviews.apache.org/groups/lucene/ listing).
>
> The review board seems so far unware of the svn-to-git migration. Other
> projects have dual listings e.g. hive and hive-git or zookeeper and
> zookeeper-git.
>
> If no one else is looking yet then I'd be happy to look into setting up a
> lucene-solr-git reviews.apache.org entry?
>
> Christine
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Merge vs Rebase

[david.w.smi...@gmail.com]

Rob,
I'll trust your assessment of the technical deficiencies of the Hadoop
codebase as I have no experience to say one way or the other.  But I'm
confused why this is relevant to wether they have a decent process & docs
on how to use git?

For reference I think Erick is referring to this:
https://wiki.apache.org/hadoop/HowToCommit
and perhaps just the "Commit individual patches" section.

FWIW I like the documentation there.  Relatively succinct and represents
almost exactly how I plan to work with Lucene/Solr going forward, albeit
through IntelliJ and not at the command-line.

My only critique of it is that I sense the git branch.autosetuprebase
option (what Yonik is using) might be obsoleted by the pull.rebase option;
I like the latter (newer option) better; and it makes no sense to use
both.  This is a nitpick though; the result is rebasing on pull.

~ David

On Tue, Jan 26, 2016 at 9:06 AM Robert Muir  wrote:

> I am entirely serious, but we all know the code quality problems with
> hadoop. Many are the same ones Uwe has already fought here and you can
> already find issues/discussions on them:
>
> * any hadoop maven artifact is "jar hell in a box"
> * hadoop classes do crazy shit, like execute operating system
> processes when classes load.
> * at the same time, hadoop is not really portable (e.g. hdfs just
> fails on windows without native libraries).
>
> furthermore, I have seen a push for a lot of apache projects to follow
> a "typical" hadoop-like development style. You can recognize certain
> features of it like trying to enforce code reviews,
> review-then-commit, etc. It recently caused a big thread on the
> incubator lists. personally, I agree with some of the comments there,
> that making it too hard to get commits in discourages code cleanups
> and things like that (which appear to be desperately needed if you
> actually look at the code)
>
> I also think their approach to backwards compatibility and JVM version
> support plays a big role. If they stopped pretending they could run on
> ancient java versions and just adopted java 7, they would actually be
> *more* portable (e.g. work on windows) and not less. Also use of NIO.2
> instead of trying to execute processes like 'ln -s' for handling files
> is way cleaner.
>
> On Tue, Jan 26, 2016 at 8:03 AM, Erik Hatcher 
> wrote:
> > Robert - not sure if you're serious or not but I'd love to see an
> example of the (lack of?) code quality especially in how the dev practices
> there contributed to it. Pointers?
> >
> >Erik
> >
> >> On Jan 26, 2016, at 06:16, Robert Muir  wrote:
> >>
> >> I don't think we should follow the hadoop dev practices, just look at
> >> the quality of the code they produce...
> >>
> >>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <
> erickerick...@gmail.com> wrote:
> >>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> >>> start and we can refine as necessary.
> >>>
> >>> I'll put big banners about "PRELIMINARY" in it, and add bits about
> >>> this being recommended not required.
> >>>
> >>> Thoughts?
> >>>
>  On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler 
> wrote:
>  Hi,
> 
> > Another chore we do is on adding new files is
> > svn propset svn:eol-style native 
> >
> > do we have an equivalent for that in git?
> 
>  Per-file properties like eol-style or MIME-type don't exist. Git has
> some set of internal file extensions it treats as text files and does the
> newlines automagically. If we want to configure that, we can commit a
> ".gitconfig" file in root directory of repository:
> https://help.github.com/articles/dealing-with-line-endings/
> 
>  I would like to add such a .gitconfig file in any case to do some
> sane defaults.
> 
>  The ANT checker in "precommit" now also checks your GIT working copy
> and fails like before, although it no longer looks at mime types or
> eol-style.
> 
>  Uwe
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: 

Re: Hmm Git mistake I believe

[david.w.smi...@gmail.com]

I understand it is "accurate" in the sense that it is more detailed as to
what transpired -- at a cost of making the commit log more confusing should
everyone do this.  But I think this extra information is moot in simple
cases like this -- i.e. "simple" in the sense that what he's working on
didn't warrant a feature branch -- the vast majority of cases.  Lets say he
rebases.  And lets say, he had to address some merge conflicts, and that
some error was made -- perhaps too much beer :-).  We determine there's a
bug introduced at his commit but was absent at the commit prior.  Clearly
this commit introduced the bug and then we can go looking to see why.  This
is just like our current dev practice that we've done with subversion, and
note we didn't desire to change our dev practices (yet), even if git
enables new options.   You know -- one step at a time?  Also, sometimes
wether there's a merge commit or not winds up being arbitrary.  For
example, if Joel had developed, tested, *then* pulled (and resolved any
conflicts as necessary & tested again), *then* committed, there would be no
merge commit bubble.  Thus the presence of the merge bubble is arbitrary;
sometimes it'll be there in our logs; sometimes not, even if none of us do
rebase pulls.  So that defeats the meaningfulness of those merge commits.

~ David

On Tue, Jan 26, 2016 at 11:37 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Why is this a problem?
>
> It records the fact that you had pull'd and had to merge your changes
> with what "came in" from master from other devs.
>
> Such historical accuracy, while looking "dirty" to some devs, is
> nevertheless accurate to what actually transpired, and can therefore
> be useful to future devs digging through the history.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Jan 26, 2016 at 11:18 AM, david.w.smi...@gmail.com
> <david.w.smi...@gmail.com> wrote:
> > Yup.  And when you pulled, you didn't do it via rebase.  I'll assume
> you're
> > in the camp of not wanting these merge commits and non-liinear history
> (and
> > thus loops) -- granted I don't think you explicitly stated your opinion.
> > So, even if you followed Yoniks' advice (and not mine) and thus set the
> > branch.autosetuprebase option, that AFAIK only affects repos created
> *after*
> > you set that option.  I recommend you remove that setting if you have and
> > instead set this:
> > git config --global pull.rebase true
> > (or at your discretion remove the --global and thus only set this on this
> > project).
> >
> > Cheers,
> > ~ David
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: reviews.apache.org / GIT migration

[david.w.smi...@gmail.com]

Thanks for the input guys.

On Tue, Jan 26, 2016 at 2:37 PM Mike Drob <md...@apache.org> wrote:

> To add another possibility to the mix, I'd suggest using something like
> Apache Yetus to manage commit process.
>
> On Tue, Jan 26, 2016 at 1:22 PM, Gregory Chanan <gcha...@cloudera.com>
> wrote:
>
>> IMO reviewboard with git is strictly better than reviewboard with svn;
>> getting reviewboard from svn to accept my patches was always a chore --
>> I've never had that problem with git.
>>
>> I have mixed feelings about gerrit.  The main advantages are:
>> 1) automatic pre commit checks (i.e. I can have it run the unit tests /
>> precommit when I put a patch up for review), no extra effort on my part or
>> taxing of my dev machine.
>> 2) better source repository integration.  I can see which patches have
>> been committed and which haven't and it's easier to submit and track
>> multiple changes that depend on each other).  I can also set it up to
>> commit to the repository the way I want (i.e. always cherry pick).
>>
>> The downside is the UI is just awful, at least for the version I'm used
>> to.  As an example, I haven't even figured out a good way of replying to a
>> review comment without copying the comment (from a different page!),
>> pasting it and adding my own quotes so it's clear which comment I'm
>> referring to.
>>
>> So, if you are looking for a tool to assist in reviews, I would recommend
>> Review Board.  If you are looking for a tool to help you manage the commit
>> process, gerrit does that pretty well.
>>
>> Greg
>>
>> On Tue, Jan 26, 2016 at 7:42 AM, david.w.smi...@gmail.com <
>> david.w.smi...@gmail.com> wrote:
>>
>>> +1; I can't see how anyone would object to adding/retaining support for
>>> the tool.  Nobody is forced to use it.
>>>
>>> I'm curious of the move to Git allows for possibly better options.  I've
>>> heard good things about Gerrit but I've never tried it.  I have mixed
>>> feelings of my experience with Reviewboard, but *anything* beats reviewing
>>> big patch files!
>>>
>>> Mark, Greg what do you guys think?  I recall you two used it too.
>>>
>>> On Tue, Jan 26, 2016 at 10:33 AM Christine Poerschke (BLOOMBERG/ LONDON)
>>> <cpoersc...@bloomberg.net> wrote:
>>>
>>>> Looks like https://issues.apache.org/jira/browse/INFRA-7630 set up the
>>>> original/existing review board. If there are no objections or existing
>>>> ticket then I will raise a similar ticket towards the end of this week.
>>>>
>>>> Christine
>>>>
>>>> - Original Message -
>>>> From: dev@lucene.apache.org
>>>> To: dev@lucene.apache.org
>>>> At: Jan 26 2016 15:18:22
>>>>
>>>> Hello.
>>>>
>>>> Having not used it before, I'd like to try out reviews.apache.org
>>>> (even though it's only been used a few times for the project in the past
>>>> based on the https://reviews.apache.org/groups/lucene/ listing).
>>>>
>>>> The review board seems so far unware of the svn-to-git migration. Other
>>>> projects have dual listings e.g. hive and hive-git or zookeeper and
>>>> zookeeper-git.
>>>>
>>>> If no one else is looking yet then I'd be happy to look into setting up
>>>> a lucene-solr-git reviews.apache.org entry?
>>>>
>>>> Christine
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Merge vs Rebase

[david.w.smi...@gmail.com]

>> git merge --squash myfeature
>>> git commit -m "myfeature"
>>>
>>> By the way -- having those "bubbles" in history can be perceived as
>>> beneficial if you merge features that have multiple commits because
>>> then you "see" all the intermediate commits and you can revert the
>>> entire feature in one step (as opposed to multiple fast-forward
>>> commits).
>>>
>>> Dawid
>>>
>>>
>>>
>>> Dawid
>>>
>>>
>>> On Mon, Jan 25, 2016 at 9:34 AM, Uwe Schindler <u...@thetaphi.de> wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > I am fine with both. The example of the conflict between my commit and
>>> > Mike’s is just a “normal usecase”. To me it looks correct how it is
>>> shown in
>>> > history. At least it shows reality: 2 people were about to commit the
>>> same.
>>> > This happened with SVN many times, too, but you are right it was
>>> solved by
>>> > SVN through additional update (a rebase) and then try commit again. I
>>> am
>>> > fine with both variants. But if we decide to only do one variant, I’d
>>> prefer
>>> > to have some “howto chart” what you need to do to setup your working
>>> copy
>>> > correctly (all commands for configuring @apache.org username, pull
>>> > settings,…) that are local to the repository. Maybe add a
>>> shell/windows.cmd
>>> > script to devtools! I don’t want to change those settings globaly, so
>>> please
>>> > don’t use the magic –global setting in the example.If we have a
>>> script, we
>>> > can do that per WC:
>>> >
>>> > -  Fetch repo from git-wip-us
>>> >
>>> > -  Run script
>>> >
>>> >
>>> >
>>> > About merge: When we get pull requests from 3rd parties, we should
>>> > definitely not rebase With merging that in (in the same way how
>>> Githiub
>>> > is doing it), we preserve attribution to the original commiter. We
>>> should
>>> > really keep that! That is to me the only good reason to use Git!
>>> >
>>> >
>>> >
>>> > I am fine with rebasing our own stuff and make it a slight as
>>> possible, but
>>> > for stuff from 3rd party people, we should really preserve what they
>>> did! So
>>> > I will always use the command in the github pull request mail and
>>> apply that
>>> > to my working copy and push.
>>> >
>>> >
>>> >
>>> > Uwe
>>> >
>>> >
>>> >
>>> > -
>>> >
>>> > Uwe Schindler
>>> >
>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>> >
>>> > http://www.thetaphi.de
>>> >
>>> > eMail: u...@thetaphi.de
>>> >
>>> >
>>> >
>>> > From: Shai Erera [mailto:ser...@gmail.com]
>>> > Sent: Monday, January 25, 2016 8:50 AM
>>> > To: dev@lucene.apache.org
>>> > Subject: Re: Merge vs Rebase
>>> >
>>> >
>>> >
>>> > I agree David. I'm sure there are valid use cases for merging commits,
>>> but I
>>> > always prefer rebasing. This has been our way with Apache SVN anyway,
>>> so why
>>> > change it? I fell like merging only adds unnecessary lines to 'git
>>> log',
>>> > where you see "Merge commits (1, 7)" but this doesn't add much
>>> information
>>> > to whoever looks at it.
>>> >
>>> > What does it matter if this merge commit is from previous master and
>>> > feature-commit? Why do we need one additional commit per change?
>>> >
>>> > I'm not a Git expert, but I know (think...) that if you merge C1 and
>>> C2, and
>>> > C2 is a parent of C1, Git doesn't do a merge commit. Someone probably
>>> can
>>> > confirm that.
>>> >
>>> > FWIW, I plan to continue working the 'SVN' way by doing the following:
>>> >
>>> > git checkout master
>>> >
>>> > git pull --rebase (update to latest commit/rev)
>>> >
>>> > git checkout -b feature
>>> >
>>> > git commit -a -m "feature message"
>>> >
>>> > git commit --amend (applying

Merge vs Rebase

[david.w.smi...@gmail.com]

[image: lucene-merge-commit-pic.png]

Just to put a little picture to this, I noticed the following:  (see
attached pic)
I suspect it was the bi-product of using a merge based pull (I think the
default?) instead of a rebase one, and as a result we have this little loop
in the log.  No doubt there is a place for merge commits (e.g. merging one
feature branch and another); but is there an advocate willing to tell us
the virtues that in this instance (not all instances but this one), it's a
good thing?  i.e. is there some insight this loop shows that that I should
value more than a direct simple lineage?

FWIW I prefer to rebase my commits to prevent these little merge bubbles.
It happens automatically with this setting:
   git config --global pull.rebase true
Alternatively it could be done without the --global flag.  I would most
appreciate it if other committers used this same setting, and I think we'd
all mutually appreciate it as well with cleaner git histories.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: intellij git history

[david.w.smi...@gmail.com]

THANKS!
On Sun, Jan 24, 2016 at 11:26 AM Dawid Weiss <dawid.we...@gmail.com> wrote:

> I will do it.
>
> D.
>
> On Sun, Jan 24, 2016 at 3:06 PM, Uwe Schindler <u...@thetaphi.de> wrote:
> > Hi,
> >
> > I tried it out locally: It is quite easy to use "rebase" and step over
> those 2 commits. So you can just remove them, because they are together
> basically a no-op (remove all and then add all back).
> >
> > I can do that for both branches and then do a "git push --force" of the
> rewritten history? Any comments?
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> >> -Original Message-
> >> From: Dawid Weiss [mailto:dawid.we...@gmail.com]
> >> Sent: Sunday, January 24, 2016 9:59 AM
> >> To: dev@lucene.apache.org
> >> Subject: Re: intellij git history
> >>
> >> We can move the reference for master and branch_5x -- these are
> >> affected. I can do it tonight and cherry pick any commits that have
> >> been added since then.
> >>
> >> Dawid
> >>
> >> On Sun, Jan 24, 2016 at 7:07 AM, david.w.smi...@gmail.com
> >> <david.w.smi...@gmail.com> wrote:
> >> > I'm seeing this too Yonik :-(  This really sucks.  I googled and
> found this:
> >> >
> >> > http://stackoverflow.com/questions/27797965/showing-graphically-the-
> >> equivalent-of-git-log-follow-in-intellij
> >> > Which makes reference to 2 IntelliJ issue tracker bug reports, both
> marked
> >> > as closed years ago.  In summary, Jetbrains says IntelliJ has its own
> rename
> >> > detection algorithm and deliberately doesn't use "--follow" because it
> >> > alleges it to be buggy.
> >> >
> >> > What to do?  I'm sure it's controversial to suggest this but... why
> did we
> >> > need this delete all & re-add commits in the first place?  I'm +1 to
> a force
> >> > push to omit them; it will never be easier to do this than now (just 4
> >> > branches).  FWIW IntelliJ's algorithm *does* follow
> SearchComponent.java
> >> > from just prior to this to its inception in 2007 -- my go-to test this
> >> > feature works.  I tested this by adding a branch based on a hash from
> just
> >> > prior to these commits and then viewing the history of this file (all
> via
> >> > IntelliJ).
> >> >
> >> > ~ David
> >> >
> >> > On Sat, Jan 23, 2016 at 10:27 PM Mark Miller <markrmil...@gmail.com>
> >> wrote:
> >> >>
> >> >> Just a guess, but perhaps the follow option will help?
> >> >> On Sat, Jan 23, 2016 at 9:56 PM Yonik Seeley <ysee...@gmail.com>
> wrote:
> >> >>>
> >> >>> Everything looks fine from the command line, but Intellij  IDEA 14
> >> >>> doesn't seem to be able to see the history:
> >> >>>
> >> >>> If I right click on a file and do "GIT->Show History" I only see a
> single
> >> >>> entry:
> >> >>>
> >> >>> * 2c97a68 2016-01-23 | Revert "LUCENE-6937: moving trunk from SVN to
> >> >>> GIT." Welcome to GIT world. [Dawid Weiss]
> >> >>>
> >> >>> Anyone else see this?
> >> >>>
> >> >>> -Yonik
> >> >>>
> >> >>>
> -
> >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >> >>>
> >> >> --
> >> >> - Mark
> >> >> about.me/markrmiller
> >> >
> >> > --
> >> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> > http://www.solrenterprisesearchserver.com
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: intellij git history

[david.w.smi...@gmail.com]

I'm seeing this too Yonik :-(  This really sucks.  I googled and found this:

http://stackoverflow.com/questions/27797965/showing-graphically-the-equivalent-of-git-log-follow-in-intellij
Which makes reference to 2 IntelliJ issue tracker bug reports, both marked
as closed years ago.  In summary, Jetbrains says IntelliJ has its own
rename detection algorithm and deliberately doesn't use "--follow" because
it alleges it to be buggy.

What to do?  I'm sure it's controversial to suggest this but... why did we
need this delete all & re-add commits in the first place?  I'm +1 to a
force push to omit them; it will never be easier to do this than now (just
4 branches).  FWIW IntelliJ's algorithm *does* follow SearchComponent.java
from just prior to this to its inception in 2007 -- my go-to test this
feature works.  I tested this by adding a branch based on a hash from just
prior to these commits and then viewing the history of this file (all via
IntelliJ).

~ David

On Sat, Jan 23, 2016 at 10:27 PM Mark Miller  wrote:

> Just a guess, but perhaps the follow option will help?
> On Sat, Jan 23, 2016 at 9:56 PM Yonik Seeley  wrote:
>
>> Everything looks fine from the command line, but Intellij  IDEA 14
>> doesn't seem to be able to see the history:
>>
>> If I right click on a file and do "GIT->Show History" I only see a single
>> entry:
>>
>> * 2c97a68 2016-01-23 | Revert "LUCENE-6937: moving trunk from SVN to
>> GIT." Welcome to GIT world. [Dawid Weiss]
>>
>> Anyone else see this?
>>
>> -Yonik
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> - Mark
> about.me/markrmiller
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Question about release plans amidst the git transition

[david.w.smi...@gmail.com]

+1 fine idea Rob!

On Thu, Jan 21, 2016 at 2:18 AM Robert Muir  wrote:

> one idea, we could use it to our advantage: as soon as we go to git,
> immediately (e.g. after just a few days or whatever) start a 5.5
> release?
>
> besides keeping things less confusing, it could make the 6.0 release
> more easygoing. because we'd have already worked through the pain of
> release process and tooling changes with a technically "easier"
> release otherwise. IMO basically a major release is hard enough on its
> own, we might want to separate the two things...
>
> basically we'd suffer the one-time pain of "first git release"
> immediately up-front, when svn->git is fresh in our minds. after that
> first release its on the wiki and no big deal...
>
> guess there are downsides to this idea too, e.g. it'd be effort that
> could be spent on 6.0, having to backport git build system changes to
> 5.x, etc.
>
> On Wed, Jan 20, 2016 at 6:58 PM, Shawn Heisey  wrote:
> > All indications I've seen are that there will be no 5.5 release, that
> once
> > the git transition is complete, the focus will be on stabilizing the 6.0
> > release.  Is this a correct statement?  There are quite a lot of things
> > mentioned in the 5.5 section of CHANGES.txt, plenty for a minor release.
> >
> > If we are abandoning work on branch_5x, I am OK with it, I'm just looking
> > for information.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [VOTE] Release Lucene/Solr 5.4.1 RC1

[david.w.smi...@gmail.com]

Clearly to me, the facet bug is a critical one to get into the release (and
so is index corruption) and I'm glad it was caught in time to make it into
this release.  I think these are the only "critical" issues I'm aware of so
I'm not concerned about "the floodgates opening" unless I hear of other
clearly non-critical issues jump on too.

Thanks for doing the release Adrien!
~ David

On Sat, Jan 16, 2016 at 8:24 PM Erick Erickson 
wrote:

> bq: How is this issue critical?
>
> Well, a heck of a lot of clients I deal with use facets to do analysis
> of their corpi, think of it as "poor man's stats". To tell them that
> "well, the facet counts will not be accurate sometimes" is a tough
> pill to swallow.
>
> Where we're at with this is essentially telling Solr users "skip all
> 5.3 and 5.4 versions if you want your facet counts to be accurate".
> Which sets the bar for releasing a 5.5 I guess.
>
> That said I can deal with some fuzziness on facet counts, but I really
> can't deal with index corruption so I guess it's a judgement call.
>
>
>
> On Sat, Jan 16, 2016 at 11:41 AM, Robert Muir  wrote:
> > I don't think we should open the floodgates. How is this issue critical?
> >
> > We need to get the index corruption fix out. +1 to release as is.
> >
> > On Sat, Jan 16, 2016 at 11:03 AM, Ramkumar R. Aiyengar
> >  wrote:
> >> I missed the initial RC, but if we are going to re-spin (and looks like
> >> Yonik has a patch up now), I would like to back-port SOLR-8418. Should
> be
> >> fairly benign, let me know if there are any concerns..
> >>
> >> On Fri, Jan 15, 2016 at 5:59 PM, Adrien Grand 
> wrote:
> >>>
> >>> Thanks Yonik, let's see what this bug boils down to and how quickly we
> can
> >>> get it fixed.
> >>>
> >>> Le ven. 15 janv. 2016 à 17:15, Yonik Seeley  a
> écrit :
> 
>  We've discovered a very serious bug, currently unknown how deep it
>  runs, but may make sense to respin if we can get it ironed out quickly
>  enough:
>  https://issues.apache.org/jira/browse/SOLR-8496
> 
>  -Yonik
> 
> 
>  On Thu, Jan 14, 2016 at 5:41 AM, Adrien Grand 
> wrote:
>  > Please vote for the RC1 release candidate for Lucene/Solr 5.4.1
>  >
>  > The artifacts can be downloaded from:
>  >
>  >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.1-RC1-rev1724447/
>  >
>  > You can run the smoke tester directly with this command:
>  > python3 -u dev-tools/scripts/smokeTestRelease.py
>  >
>  >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.1-RC1-rev1724447/
>  >
>  > The smoke tester already passed for me both with the local and
> remote
>  > artifacts, so here is my +1.
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >>
> >>
> >>
> >> --
> >> Not sent from my iPhone or my Blackberry or anyone else's
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [JENKINS] Lucene-Solr-5.4-Linux (32bit/jdk1.8.0_66) - Build # 390 - Still Failing!

[david.w.smi...@gmail.com]

I've seen this once before and will investigate this weekend.
On Sat, Jan 16, 2016 at 8:33 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.4-Linux/390/
> Java: 32bit/jdk1.8.0_66 -server -XX:+UseConcMarkSweepGC
>
> 1 tests failed.
> FAILED:
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.testRandom {
> seed=[E872D6DAC40C4B76:B1E69CA82980CD0]}
>
> Error Message:
> maxY must be >= minY: 0.528353445127776 to 0.5283534451277759
>
> Stack Trace:
> com.spatial4j.core.exception.InvalidShapeException: maxY must be >= minY:
> 0.528353445127776 to 0.5283534451277759
> at
> __randomizedtesting.SeedInfo.seed([E872D6DAC40C4B76:B1E69CA82980CD0]:0)
> at
> com.spatial4j.core.context.SpatialContext.makeRectangle(SpatialContext.java:218)
> at
> org.apache.lucene.spatial.SpatialTestCase.randomRectangle(SpatialTestCase.java:175)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.testRandom(HeatmapFacetCounterTest.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> 

Re: [VOTE] Release Lucene/Solr 5.4.1 RC1

[david.w.smi...@gmail.com]

+1

SUCCESS! [0:53:42.286712]


On Thu, Jan 14, 2016 at 5:41 AM Adrien Grand  wrote:

> Please vote for the RC1 release candidate for Lucene/Solr 5.4.1
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.1-RC1-rev1724447/
>
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.1-RC1-rev1724447/
>
> The smoke tester already passed for me both with the local and remote
> artifacts, so here is my +1.
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [VOTE] Release Lucene/Solr 5.3.2-RC1

[david.w.smi...@gmail.com]

+1

SUCCESS! [0:49:17.877825]


On Tue, Jan 12, 2016 at 8:21 AM Anshum Gupta  wrote:

> I forgot to add my own +1.
>
> SUCCESS! [0:36:47.637916]
>
> On Tue, Jan 12, 2016 at 2:07 AM, Anshum Gupta 
> wrote:
>
>> Please vote for the RC1 release candidate for Lucene/Solr 5.3.2
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.2-RC1-rev1723976
>>
>> You can run the smoke tester directly with this command:
>> python3 -u dev-tools/scripts/smokeTestRelease.py
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.2-RC1-rev1723976
>>
>> Sorry for the super long delay but my internet connection required 4
>> attempts to commit the RC.
>> --
>> Anshum Gupta
>>
>
>
>
> --
> Anshum Gupta
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: 5.4.1 release

[david.w.smi...@gmail.com]

Adrien, Mike: Thanks for working on a 5.4.1 release.

IMO the bug you pointed out (LUCENE-2229) should be back-ported because I
can't imagine someone depending on this behavior.  Its ultimately a bug in
the sizing of the fragment, and furthermore only occurs in infrequent
circumstances.

RE Solr: The 5.3.1 changes ought to move to 5.4.1, since these changes
post-dated 5.4.0.  Anshum what's the deal with 5.3.1?

~ David

On Mon, Jan 11, 2016 at 10:48 AM Adrien Grand  wrote:

> All changes in the "Bug Fixes" section of 5.5 of Lucene have been
> backported to 5.4.1 but https://issues.apache.org/jira/browse/LUCENE-2229
> (thanks Mike for the help). The reason is that it changes the behaviour of
> the highlighter and I'm afraid that some users might be relying on or
> expecting this bug, so I'd rather fold it into a minor release than a
> bugfix release.
>
> I'm not really qualified to know if there are things worth backporting on
> the Solr side, so if you feel like some issues should be backported for
> this bugfix release, feel free to go ahead.
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Breaking Java back-compat in Solr

[david.w.smi...@gmail.com]

Great topic Anshum.

I’ve been frustrated with the back-compat situation since Lucene/Solr 5 as
a maintainer of my “SolrTextTagger”.  One version of the plugin supports
4.3 thru the end of the 4x line, whereas on the 5x side I’ve needed 3
versions already (5.0-5,1, 5.2, 5.3+)!  Sometimes on the API consumer side
there is simply a new way compatible with the old way and those don’t
bother me much; what’s annoying is just flat-out differences that can’t
easily be coded around without reflection.  But in my experience through
the SolrTextTagger (YMMV), Solr hasn’t been the main offender of such
changes — it’s Lucene changes (be it removing liveDocs bits to get
postings, changing the BytesRefAttribute signature, or something I don’t
remember now). At least twice it was avoidable IMO.  Nevertheless, we Solr
devs should come up with a back-compat policy, a simple document/paragraph
perhaps, and save it somewhere so we can refer to it.  Lets not have to dig
through the mailing list to know our policy some day in the future when we
want to explain it!

I suggest that Solr's *default* policy for any source file (Java API) that
doesn’t otherwise annotate a back-compat statement is to be permissive to
changes — developer judgement on how much back-compat makes sense to them.
I say this because the Solr code base is large and I think a relatively
small portion of it should aim for stability.  Lets take SearchComponent as
an example.  *That* needs to be stable.  But does HighlightComponent?  I
really don’t think so; besides, it only has one overridable method defined
by this class that isn’t inherited.   Oddly (IMO) there is a separate
abstraction SolrHighlighter and I can intuit that it’s this guy that was
intended to be the abstraction of the Highlighter implementation, not the
some-what generic HighlightComponent.  So arguably SolrHighlighter should
be stable.  DefaultSolrHighlighter is debatable as being stable — it’s a
specific highlighter but it has a bunch of methods designed to be
overridden (and I have done so).  So I think that’s a judgement call
(developer prerogative).

Should we apply a back-compat policy statement (either through a simple
comment or better through a new annotation), I don’t think we should feel
helpless to strictly abide by it for the entire major version range.  We
might decide that such changes are possible provided it gets at least
one +1 and no -1 veto from another developer.

Summary:
* Publish a back-compat policy/approach where we can refer to it easily.
* The default policy of source files without annotations is the developer’s
prerogative — no back-compat.
* Annotate the back-compat Java source files as-such and allow us to break
back-compat only if voted.

~ David

On Mon, Jan 4, 2016 at 11:28 AM Anshum Gupta  wrote:

> Hi,
>
> I was looking at refactoring code in Solr and it gets really tricky and
> confusing in terms of what level of back-compat needs to be maintained.
> Ideally, we should only maintain back-compat at the REST API level. We may
> annotate a few really important Java APIs where we're guarantee back-compat
> across minor versions, but we shouldn't certainly be doing that across the
> board.
>
> Thoughts?
>
> P.S: I hope this doesn't spin-off into something I fear :)
>
> --
> Anshum Gupta
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: CfP about Geospatial Track at ApacheCon, Vancouver

[david.w.smi...@gmail.com]

Thanks for the notice/invite, Uwe.  I may send a proposal suggestion your
way (& to Chris).  It’ll be tough to choose between submitting to FOSS4G NA
(May 2-5th in Raleigh NC) and ApacheCon.
~ David

On Mon, Jan 4, 2016 at 5:28 AM Uwe Schindler  wrote:

> Hi Committers, hi Lucene users,
>
> On the next ApacheCon in Vancouver, Canada (May 9 - 13 2016), there will
> be a track about geospatial data. The track is organized by Chris Mattmann
> together with George Percivall of the OGC (Open Geospatial Consortium). As
> I am also a member of OGC, they invited me to ask the Lucene Community to
> propose talks. Apache Lucene, Solr, and Elasticsearch have great geospatial
> features, this would be a good idea to present them. This is especially
> important because the current OGC standards are very RDBMS-focused (like
> filter definitions, services,...), so we can use the track to talk with OGC
> representatives to better match OGC standards with full text search.
>
> I am not sure if I can manage to get to Vancouver, but the others are
> kindly invited to submit talks. It is not yet sure if the track will be
> part of ApacheCon Core or ApacheCon BigData. I will keep you informed. If
> you have talk suggestions, please send them to me or Chris Mattmann.
> Alternatively, submit them to the Big Data track @
> http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
> (and mention geospatial track).
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: 5.3.2 bug fix release

[david.w.smi...@gmail.com]

Yikes; I’m sure that was painful.

So I just back-ported a couple issues, SOLR-8340 & SOLR-8059.  I was about
to manually keep the 5.3.2 section in branch_5x & trunk in sync but then
thought better of it.  Might as well wait until 5.3.2 is voted and then do
it, since there are bound to be others who want to do the same, so why
bother with the intermediate bookkeeping.

On Mon, Dec 28, 2015 at 8:13 AM Anshum Gupta  wrote:

> Sorry for the long delay but I burnt my hand and so have been MIA. It's
> better now so I'll port the issues and cut an RC on Wednesday.
>
> On Wed, Dec 23, 2015 at 9:22 PM, Anshum Gupta 
> wrote:
>
>> I've added the section for 5.3.2 in all the branches. Kindly back-port
>> stuff that you think makes sense to go into a 'bug-fix' release for 5.3.1
>> only.
>>
>> I think it'd make sense to duplicate entries for JIRAs we back port.
>>
>> On Mon, Dec 21, 2015 at 11:38 AM, Anshum Gupta 
>> wrote:
>>
>>> Seems like Noble ran addVersion.py for 5.3.2 on the lucene_solr_5_3
>>> branch during the 5.3.1 release.
>>> I can now run it for branch_5x and trunk with the old change id but
>>> there are a ton of property changes to multiple files. Can someone confirm
>>> that it'd be fine? The addVersion on 5.3.2, that I'm trying to merge onto
>>> branch_5x and trunk was done before 5.4 was released.
>>>
>>> Also, the change log entry for 5.3.2 is right above 5.3.1 and not
>>> chronological i.e. at the top. I think that is how it should be unless
>>> someone has some different ideas.
>>>
>>> On Thu, Dec 17, 2015 at 2:42 AM, Shawn Heisey 
>>> wrote:
>>>
 On 12/16/2015 1:08 PM, Anshum Gupta wrote:
 > There are a bunch of important bug fixes that call for a 5.3.2 in my
 > opinion. I'm specifically talking about security plugins related fixes
 > but I'm sure there are others too.
 >
 > Unless someone else wants to do it, I'd volunteer to do the release
 > and cut an RC next Tuesday.

 Sounds like a reasonable idea to me.  I assume these must be fixes that
 are not yet backported.

 I happen to have the 5.3 branch on my dev system, with SOLR-6188
 applied.  It is already up to date.  There's nothing in the 5.3.2
 section of either CHANGES.txt file.  The svn log indicates that nothing
 has been backported since the 5.3.1 release was cut.

 Perhaps SOLR-6188 could be added to the list of fixes to backport.  I
 believe it's a benign change.

 Thinking about CHANGES.txt, this might work for the 5.3 branch:

 
 === Lucene 5.3.2 ===
 All changes were backported from 5.4.0.

 Bug Fixes

 * LUCENE-: A description (Committer Name)
 

 If we decide it's a good idea to mention the release in trunk and
 branch_5x, something like the following might work, because that file
 should already contain the full change descriptions:

 
 === Lucene 5.3.2 ===
 The following issues were backported from 5.4.0:
 LUCENE-
 LUCENE-
 

 Thanks,
 Shawn


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>
>
> --
> Anshum Gupta
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Cassandra Targett to the Lucene / Solr PMC

[david.w.smi...@gmail.com]

Welcome Cassandra!

On Thu, Dec 24, 2015 at 10:54 AM Steve Rowe  wrote:

> I'm pleased to announce that Cassandra has accepted the PMC's invitation
> to join.
>
> Welcome Cassandra!
>
> Steve
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: 5.3.2 bug fix release

[david.w.smi...@gmail.com]

I’d like to backport SOLR-8059 & SOLR-8060 (same as SOLR-8340): NPEs that
can happen in DebugComponent & HighlightComponent when
distrib.singlePass=true (which is implied under certain conditions even if
not explicitly =true).

On Thu, Dec 17, 2015 at 8:54 AM Jan Høydahl  wrote:

> If there is a 5.3.2 release, we should probably also backport this one:
>
> SOLR-8269 : Upgrade
> commons-collections to 3.2.2. This fixes a known serialization vulnerability
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 17. des. 2015 kl. 07.35 skrev Anshum Gupta :
>
> Yes, there was already a 5.3.2 version in JIRA. I will start back-porting
> stuff to the lucene_solr_5_3 branch later in the day today.
>
>
> On Thu, Dec 17, 2015 at 11:35 AM, Noble Paul  wrote:
>
>> Agree with Shawn here.
>>
>> If a company has already done the work to upgrade their systems to
>> 5.3.1 , they would rather have a bug fix for the old version .
>>
>> So anshum, is there a 5.3.2 version created in JIRA? can we start
>> tagging issues to that release so that we can have a definitive list
>> of bugs to be backported
>>
>> On Thu, Dec 17, 2015 at 10:27 AM, Anshum Gupta 
>> wrote:
>> > Thanks for explaining it so well Shawn :)
>> >
>> > Yes, that's pretty much the reason why it makes sense to have a 5.3.2
>> > release.
>> >
>> > We might even need a 5.4.1 after that as there are more security bug
>> fixes
>> > that are getting committed as the feature is being tried by users and
>> bugs
>> > are being reported.
>> >
>> > On Thu, Dec 17, 2015 at 3:28 AM, Shawn Heisey 
>> wrote:
>> >>
>> >> On 12/16/2015 2:15 PM, Upayavira wrote:
>> >> > Why don't people just upgrade to 5.4? Why do we need another release
>> in
>> >> > the 5.3.x range?
>> >>
>> >> I am using a third-party custom Solr plugin.  The latest version of
>> that
>> >> plugin (which I have on my dev server) has only been certified to work
>> >> with Solr 5.3.x.  There's a chance that it won't work with 5.4, so I
>> >> cannot use that version yet.  If I happen to need any of the fixes that
>> >> are being backported, an official 5.3.2 release would allow me to use
>> >> official binaries, which will make my managers much more comfortable
>> >> than a version that I compile myself.
>> >>
>> >> Additionally, the IT change policies in place for many businesses
>> >> require a huge amount of QA work for software upgrades, but those
>> >> policies may be relaxed for hotfixes and upgrades that are *only*
>> >> bugfixes.  For users operating under those policies, a bugfix release
>> >> will allow them to fix bugs immediately, rather than spend several
>> weeks
>> >> validating a new minor release.
>> >>
>> >> There is a huge amount of interest in the new security features in
>> >> 5.3.x, functionality that has a number of critical problems.  Lots of
>> >> users who need those features have already deployed 5.3.1.  Many of the
>> >> critical problems are fixed in 5.4, and these are the fixes that Anshum
>> >> wants to make available in 5.3.2.  If a user is in either of the
>> >> situations that I outlined above, upgrading to 5.4 may be unrealistic.
>> >>
>> >> Thanks,
>> >> Shawn
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Anshum Gupta
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr git mirror will soon turn off

[david.w.smi...@gmail.com]

+1 totally agree.  Any way; the bloat should largely be the binaries &
unrelated projects, not code (small text files).

On Wed, Dec 16, 2015 at 10:36 PM Doug Turnbull <
dturnb...@opensourceconnections.com> wrote:

> In defense of more history immediately available--it is often far more
> useful to poke around code history/run blame to figure out some code than
> by taking it at face value. Putting this in a secondary place like
> Apache SVN repo IMO reduces the readability of the code itself. This is
> doubly true for new developers that won't know about Apache's SVN. And
> Lucene can be quite intricate code. Further in my own work poking around in
> github mirrors I frequently hit the current cutoff. Which is one reason I
> stopped using them for anything but the casual investigation.
>
> I'm not totally against a cutoff point, but I'd advocate for exhausting
> other options first, such as trimming out unrelated projects, binaries, etc.
>
> -Doug
>
>
> On Wednesday, December 16, 2015, Shawn Heisey  wrote:
>
>> On 12/16/2015 5:53 PM, Alexandre Rafalovitch wrote:
>> > On 16 December 2015 at 00:44, Dawid Weiss 
>> wrote:
>> >> 4) The size of JARs is really not an issue. The entire SVN repo I
>> mirrored
>> >> locally (including empty interim commits to cater for svn:mergeinfos)
>> is 4G.
>> >> If you strip the stuff like javadocs and side projects (Nutch, Tika,
>> Mahout)
>> >> then I bet the entire history can fit in 1G total. Of course stripping
>> JARs
>> >> is also doable.
>> > I think this answered one of the issues. So, this is not something to
>> focus on.
>> >
>> > The question I had (I am sure a very dumb one): WHY do we care about
>> > history preserved perfectly in Git? Because that seems to be the real
>> > bottleneck now. Does anybody still checks out an intermediate commit
>> > in Solr 1.4 branch?
>>
>> I do not think we need every bit of history -- at least in the primary
>> read/write repository.  I wonder how much of a size difference there
>> would be between tossing all history before 5.0 and tossing all history
>> before the ivy transition was completed.
>>
>> In the interests of reducing the size and download time of a clone
>> operation, I definitely think we should trim history in the main repo to
>> some arbitrary point, as long as the full history is available
>> elsewhere.  It's my understanding that it will remain in svn.apache.org
>> (possibly forever), and I think we could also create "historical"
>> read-only git repos.
>>
>> Almost every time I am working on the code, I only care about the stable
>> branch and trunk.  Sometimes I will check out an older 4.x tag so I can
>> see the exact code referenced by a stacktrace in a user's error message,
>> but when this is required, I am willing to go to an entirely different
>> repository and chew up bandwidth/disk resourcesto obtain it, and I do
>> not care whether it is git or svn.  As time marches on, fewer people
>> will have reasons to look at the historical record.
>>
>> Thanks,
>> Shawn
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
> *Doug Turnbull **| *Search Relevance Consultant | OpenSource Connections
> , LLC | 240.476.9983
> Author: Relevant Search 
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: accessing Lucene package members from Solr

[david.w.smi...@gmail.com]

Good day Mikhail.
Without looking at the details, I have no qualms about making a method
public if you need to call it from another package.  Just add
@lucene.internal to the method; perhaps warn in comments that it’s likely
going away in 6.0.
~ David

On Fri, Dec 11, 2015 at 2:47 PM Mikhail Khludnev 
wrote:

> Good day!
>
> While working on SOLR-5743, which nobody wants to comment, I face the
> problem.
> Collector from Solr codebase should call package visible member:
> o.a.l.s.join.ToParentBlockJoinQuery.BlockJoinScorer.swapChildDocs(int[])
>
> I see the following alternatives:
> - straightforwardly, make BlockJoinScorer.swapChildDocs(int[]) public;
> - trickily add public class, which allows to call swapChildDocs() into
> o.a.l.s.join. and call this accessor from Solr.
> - meanly put Solr class in Solr codebase into lucene package o.a.l.s.join.
>
> The context is that so far it seems like an experimental feature at 5.5,
> and I can imagine that it will be removed in 6.0.Thus, the first option
> seems more doubtful to me.
>
> Which one will be healthier for Lucene?
>
> --
> Sincerely yours
>
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> 
> 
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [RESULT] [VOTE] Release Lucene/Solr 5.4.0-RC1

[david.w.smi...@gmail.com]

Nice job everyone (especially Upayavira) — we’re getting this one out the
door with no respins.  I think it’s been many releases before that last
happened.

~ David

On Thu, Dec 10, 2015 at 11:30 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> On Thu, Dec 10, 2015 at 11:24 AM, Erick Erickson
>  wrote:
>
> > Thank you!
>
> +1
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1040 - Still Failing

[david.w.smi...@gmail.com]

Mikhail,
In the future, particularly when committing code that uses Java 8 features,
be sure to compile & run tests even on the 5x branch after back-porting but
before committing.  From time to time this fails for stuff, like
easy-to-forget cases of not using ‘final’.
~ David

On Tue, Dec 8, 2015 at 2:21 AM Mikhail Khludnev 
wrote:

> It's mine. Looking into.
>
> On Tue, Dec 8, 2015 at 9:35 AM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
>> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1040/
>>
>> All tests passed
>>
>> Build Log:
>> [...truncated 7450 lines...]
>> [javac] Compiling 6 source files to
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build/join/classes/test
>> [javac]
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
>> error: cannot find symbol
>> [javac] assert nextInt ==
>> Integer.parseUnsignedInt(uniqueRandomValue,16);
>> [javac]  ^
>> [javac]   symbol:   method parseUnsignedInt(String,int)
>> [javac]   location: class Integer
>> [javac]
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
>> error: cannot find symbol
>> [javac] final int linkInt =
>> Integer.parseUnsignedInt(linkValue,16);
>> [javac]^
>> [javac]   symbol:   method parseUnsignedInt(String,int)
>> [javac]   location: class Integer
>> [javac] Note:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
>> uses or overrides a deprecated API.
>> [javac] Note: Recompile with -Xlint:deprecation for details.
>> [javac] 2 errors
>>
>> BUILD FAILED
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:801:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:738:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:59:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build.xml:472:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:2252:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/module-build.xml:58:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/module-build.xml:55:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:818:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:832:
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:1968:
>> Compile failed; see the compiler error output for details.
>>
>> Total time: 106 minutes 8 seconds
>> Build step 'Invoke Ant' marked build as failure
>> Archiving artifacts
>> Recording test results
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> 
> 
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [VOTE] Release Lucene/Solr 5.4.0-RC1

[david.w.smi...@gmail.com]

+1 for release. (tested with Java 7)

SUCCESS! [0:56:31.943245]


On Mon, Dec 7, 2015 at 8:05 PM Steve Rowe  wrote:

> +1
>
> Docs, javadocs, and changes look good.
>
> Smoke tester was happy with Java7 and Java8:
>
> SUCCESS! [1:53:58.550314]
>
> Steve
>
> > On Dec 7, 2015, at 5:31 AM, Upayavira  wrote:
> >
> > Yes, Shalin, you are right. My fix was still required, but I clearly
> > manually entered the SVN commit command wrong. Seeing as it does not
> > impact upon the contents of the files, I have executed an SVN mv
> > command, rerun the smoke test with the below, which worked:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev1718046
> >
> > Please, folks, use the above to run the smoke test for this release.
> >
> > Upayavira
> >
> > On Mon, Dec 7, 2015, at 04:00 AM, Shalin Shekhar Mangar wrote:
> >> Hi Upayavira,
> >>
> >> The svn revision in the URL is wrong. It should be 1718046 but it is
> >> 178046 which makes the smoke tester fail with the following message:
> >>
> >> RuntimeError: JAR file
> >>
> "/tmp/smoke_lucene_5.4.0_178046_1/unpack/lucene-5.4.0/analysis/common/lucene-analyzers-common-5.4.0.jar"
> >> is missing "Implementation-Version: 5.4.0 178046 " inside its
> >> META-INF/MANIFEST.MF (wrong svn revision?)
> >>
> >> I think you may need to generate a new RC. But perhaps an svn move to
> >> a path with the right revision number may also suffice?
> >>
> >> On Mon, Dec 7, 2015 at 9:12 AM, Shalin Shekhar Mangar
> >>  wrote:
> >>> Thanks Upayavira. I guess Apache has started redirecting http traffic
> >>> to https recently on dist.apache.org which must have broken this
> >>> script. I am able to run smoke tester after applying your patch.
> >>>
> >>> On Mon, Dec 7, 2015 at 2:08 AM, Upayavira  wrote:
>  The getHREFs() method is taking in an HTTPS URL, but failing to
> preserve
>  the protocol, resulting in an HTTP call that the server naturally
>  bounces to HTTPS. Unfortunately, the next loop round also forgets the
>  HTTPS, and hence we're stuck in an endless loop. Below is a patch that
>  fixes this issue. I'd rather someone with more knowledge of this
> script
>  confirm my suspicion and apply the patch for us all to use, as I
> cannot
>  see how this ever worked.
> 
>  I personally ran the smoke test on my local copy, so did not hit this
>  HTTP/HTTPS code. I'm running the HTTP version now, and will check on
> it
>  in the morning.
> 
>  Index: dev-tools/scripts/smokeTestRelease.py
>  ===
>  --- dev-tools/scripts/smokeTestRelease.py   (revision 1718046)
>  +++ dev-tools/scripts/smokeTestRelease.py   (working copy)
>  @@ -84,7 +84,12 @@
>    # Deref any redirects
>    while True:
>  url = urllib.parse.urlparse(urlString)
>  -h = http.client.HTTPConnection(url.netloc)
>  +if url.scheme == "http":
>  +  h = http.client.HTTPConnection(url.netloc)
>  +elif url.scheme == "https":
>  +  h = http.client.HTTPSConnection(url.netloc)
>  +else:
>  +  raise RuntimeError("Unknown protocol: %s" % url.scheme)
>  h.request('GET', url.path)
>  r = h.getresponse()
>  newLoc = r.getheader('location')
> 
>  Upayavira
> 
>  On Sun, Dec 6, 2015, at 06:26 PM, Noble Paul wrote:
> > Same here.
> >
> > On Sun, Dec 6, 2015 at 2:36 PM, Shalin Shekhar Mangar
> >  wrote:
> >> Is anyone able to run the smoke tester on this RC? It just hangs
> for a
> >> long time on "loading release URL" for me.
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py --tmp-dir
> >> ../smoke-5.4 --revision 178046 --version 5.4.0 --test-java8
> >> ~/programs/jdk8
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
> >> Java 1.7 JAVA_HOME=/home/shalin/programs/jdk7
> >> Java 1.8 JAVA_HOME=/home/shalin/programs/jdk8
> >> NOTE: output encoding is UTF-8
> >>
> >> Load release URL
> >> "
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
> "...
> >>
> >> I did a strace and found that the server is returning a HTTP 301
> moved
> >> permanently response to the http request.
> >>
> >> On Sat, Dec 5, 2015 at 4:28 PM, Upayavira  wrote:
> >>> Please vote for the RC1 release candidate for Lucene/Solr 5.4.0
> >>>
> >>> The artifacts can be downloaded from:
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
> >>>
> >>> You can run the smoke tester directly with this command:
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py
> >>>
> 

Re: Lucene/Solr git mirror will soon turn off

[david.w.smi...@gmail.com]

I understand Gus; but we’d like to separate the question of wether we
should move from svn to git from fixing the git mirror.  It’s contentious —
I encourage you to search the list archives for some of the arguments.

On Sat, Dec 5, 2015 at 12:53 PM Gus Heck  wrote:

> If I understand this thread (perhaps not?) The issue comes from synching
> git and svn? If we move to git only, all old versions and jars will live in
> svn so anyone who needs to build an old version is all set. The move to git
> can retain history without jars for "blame".  .
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr git mirror will soon turn off

[david.w.smi...@gmail.com]

I agree with Rob on this — delete the ‘jar’s from git history, for all the
reasons Rob said.  If someone wants to attempt to actually *build* an old
release, and thus needs the jars, then they are welcome to use ASF SVN
archives for that purpose instead, and even then apparently it will be a
challenge based on what I’ve read today.

Any way, maybe this will or maybe this won’t even solve the git-svn OOM
problem by itself?  It’s worth a shot to find out as a trial run; no?
Maybe we could ask infra to try as an experiment.  If it doesn’t solve the
problem then we needn’t belabor this decision at this time — it can be
resumed at a future git transitional discussion, which is not the subject
matter of the current crisis.

bq. I know you won't accept rational arguments. :)

Dawid, please, lets not provoke each other with that kind of talk.  The
smiley face doesn’t make it okay.

~ David

On Fri, Dec 4, 2015 at 4:26 PM Dawid Weiss  wrote:

> > I don't think jar files are 'history' and it was a mistake we had so
> > many in source control before we cleaned that up. it is much better
> > without them.
>
> Depends how you look at it. If your goal is to be able to actually
> build ancient versions then dropping those JARs is going to be a real
> pain. I think they should stay. Like I said, git is smart enough to
> omit objects that aren't referenced from the cloned branch. The
> conversion from SVN would have to be smart, but it's all doable.
>
> > this bloats the repository, makes clone slow for someone new who just
> > wants to check it out to work on it, etc.
>
> No, not really. There is a dozen ways to do it without cloning the
> full repo (provide a patch with --depth 1, clone a selective branch,
> etc.). We've had that discussion before. I know you won't accept
> rational arguments. :)
>
> D.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: 5.4 branch created, feature freeze in place (was Re: A 5.4 release?)

[david.w.smi...@gmail.com]

SOLR-8180 (jcl-over-slf4j) is there too now, some 30min ago.

On Tue, Dec 1, 2015 at 2:27 PM Upayavira  wrote:

> Thx, I hope to create the first RC tomorrow.
>
> On Tue, Dec 1, 2015, at 06:36 PM, Noble Paul wrote:
> > I'm done with SOLR-8355
> >
> > On Tue, Dec 1, 2015 at 4:24 PM, Noble Paul  wrote:
> > > hi Upayavira,
> > > sorry for the trouble. There is another blocker created
> > > https://issues.apache.org/jira/browse/SOLR-8355
> > > I'm fixing that
> > >
> > > On Mon, Nov 30, 2015 at 8:26 PM, Christine Poerschke (BLOOMBERG/
> > > LONDON)  wrote:
> > >> Fair point, I have re-worded the ticket title and summary. Will await
> > >> further opinions before applying or not applying the patch to 5.4
> branch
> > >> (and trunk and branch_5x).
> > >>
> > >> Christine
> > >>
> > >> From: dev@lucene.apache.org At: Nov 30 2015 14:29:58
> > >> To: dev@lucene.apache.org
> > >> Subject: Re: 5.4 branch created, feature freeze in place (was Re: A
> 5.4
> > >> release?)
> > >>
> > >> The patch seems innocuous enough. From the ticket though it isn't so
> clear
> > >> to me what problem it solves. I'm open to the opinion of others.
> > >>
> > >> Upayavira
> > >>
> > >> On Mon, Nov 30, 2015, at 12:09 PM, Christine Poerschke (BLOOMBERG/
> LONDON)
> > >> wrote:
> > >>
> > >> Any thoughts on getting the
> > >> https://issues.apache.org/jira/browse/LUCENE-6911 fix into 5.4 solr
> or not?
> > >> Basically StandardQueryParser's existing getMultiFields method is a
> no-op.
> > >>
> > >> From: dev@lucene.apache.org At: Nov 25 2015 14:11:46
> > >> To: dev@lucene.apache.org
> > >> Subject: Re:5.4 branch created, feature freeze in place (was Re: A 5.4
> > >> release?)
> > >>
> > >> I have created the lucene_solr_5_4 branch. Please, no new features in
> this
> > >> branch.
> > >>
> > >> Please update this thread with any changes you propose to make to this
> > >> branch. Only JIRA tickets which are a blocker and have fix version
> 5.4 will
> > >> delay a release candidate build.
> > >>
> > >> Please do review the below - and take any action to clear up these
> tickets
> > >> asap.
> > >>
> > >> I expect to create the first RC this time next week.
> > >>
> > >> Thanks!
> > >>
> > >> Upayavira
> > >>
> > >> On Wed, Nov 25, 2015, at 02:05 PM, Upayavira wrote:
> > >>
> > >> I shall shortly create the 5.4 release branch. From this moment, the
> feature
> > >> freeze starts.
> > >>
> > >> Looking through JIRA, I see some 71 tickets assigned to fix version
> 5.4. I
> > >> suspect we won't be able to fix all 71 in one week, so I expect that
> the
> > >> majority will be pushed, after this release, to 5.5.
> > >>
> > >> Looking for blockers or critical tickets, I see five tickets:
> > >>
> > >> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble)
> blocker
> > >>   "Adding read restriction to BasicAuth + RuleBased authorization
> causes
> > >> issue with replication"
> > >>
> > >>   Anusham/Noble - any thoughts on how to resolve this before the
> release?
> > >>
> > >> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
> > >>   "Move solr/webapp to solr/server/solr-webapp"
> > >>
> > >>   This one I know isn't a blocker in any sense.
> > >>
> > >> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
> > >>   "Add tests for bin/post"
> > >>
> > >>   Again, this one does not seem to be something worthy of holding
> back a
> > >> release
> > >>
> > >> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
> > >>   "Date field problems using ExtractingRequestHandler and java 9
> (b71)"
> > >>
> > >>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
> > >>
> > >> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others),
> blocker
> > >>   "Java 8 as the minimum supported JVM version for branch_5x"
> > >>
> > >>   Looking at the discussion, there was no consensus here, so I will
> not
> > >> consider this a blocker either.
> > >>
> > >>   - o -
> > >>
> > >> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention.
> Anyone
> > >> have comments/observations here?
> > >>
> > >> I will create the branch shortly.
> > >>
> > >> Upayavira
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > -
> > > Noble Paul
> >
> >
> >
> > --
> > -
> > Noble Paul
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:

Re: 5.4 branch created, feature freeze in place (was Re: A 5.4 release?)

[david.w.smi...@gmail.com]

I plan to address SOLR-8180 which is about adding jcl-over-slf4j as a
dependency on SolrJ.

On Wed, Nov 25, 2015 at 9:11 AM Upayavira  wrote:

> I have created the lucene_solr_5_4 branch. Please, no new features in this
> branch.
>
> Please update this thread with any changes you propose to make to this
> branch. Only JIRA tickets which are a blocker and have fix version 5.4 will
> delay a release candidate build.
>
> Please do review the below - and take any action to clear up these tickets
> asap.
>
> I expect to create the first RC this time next week.
>
> Thanks!
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 02:05 PM, Upayavira wrote:
>
> I shall shortly create the 5.4 release branch. From this moment, the
> feature freeze starts.
>
> Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
> suspect we won't be able to fix all 71 in one week, so I expect that the
> majority will be pushed, after this release, to 5.5.
>
> Looking for blockers or critical tickets, I see five tickets:
>
> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>   "Adding read restriction to BasicAuth + RuleBased authorization causes
> issue with replication"
>
>   Anusham/Noble - any thoughts on how to resolve this before the release?
>
> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>   "Move solr/webapp to solr/server/solr-webapp"
>
>   This one I know isn't a blocker in any sense.
>
> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>   "Add tests for bin/post"
>
>   Again, this one does not seem to be something worthy of holding back a
> release
>
> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>
>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>
> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others),
> blocker
>   "Java 8 as the minimum supported JVM version for branch_5x"
>
>   Looking at the discussion, there was no consensus here, so I will not
> consider this a blocker either.
>
>   - o -
>
> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention.
> Anyone have comments/observations here?
>
> I will create the branch shortly.
>
> Upayavira
>
>
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Next release...

[david.w.smi...@gmail.com]

+1 to not sooner than February 2016 (one year later)

On Fri, Nov 13, 2015 at 6:25 AM Adrien Grand  wrote:

> Le jeu. 12 nov. 2015 à 18:21, Erick Erickson  a
> écrit :
>
>> Are there any tentative (not firm commitments) time frames for 6.0?
>>
>
> I don't think we talked about it before. Maybe we could aim for something
> like February 2016. This would be one year after 5.0, which I think is a
> nice trade-off between us being able to drop support for old index formats
> and users not feeling to much pressure to upgrade all the time. It also
> means that features that are almost ready like the new dimensional format
> and cdcr wouldn't have to wait for too long before going into the hands of
> our users.
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Areek Zillur to the Lucene / Solr PMC

[david.w.smi...@gmail.com]

Welcome Areek!

On Wed, Nov 11, 2015 at 3:49 PM Simon Willnauer 
wrote:

> I'm pleased to announce that Areek has accepted the PMC's invitation to
> join.
>
> Welcome Areek!
>
>
> Simon
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Dennis Gove as Lucene/Solr committer

[david.w.smi...@gmail.com]

Welcome Dennis!

On Fri, Nov 6, 2015 at 10:19 AM Joel Bernstein  wrote:

> I'm pleased to announce that Dennis Gove has accepted the PMC's
> invitation to become a committer.
>
> Dennis, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Tomás Fernández Löbbe to the PMC

[david.w.smi...@gmail.com]

Welcome Tomás!

On Fri, Nov 6, 2015 at 1:16 PM Tomás Fernández Löbbe 
wrote:

> Thanks everyone!
>
> On Fri, Nov 6, 2015 at 10:05 AM, Ramkumar R. Aiyengar <
> andyetitmo...@gmail.com> wrote:
>
>> Congratulations Tomas :)
>> On 6 Nov 2015 09:53, "Anshum Gupta"  wrote:
>>
>>> I'm pleased to announce that Tomás Fernández Löbbe has accepted the
>>> PMC’s invitation to join.
>>>
>>> Welcome Tomás!
>>>
>>> --
>>> Anshum Gupta
>>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Joel Bernstein to the PMC

[david.w.smi...@gmail.com]

Welcome Joel!

On Fri, Nov 6, 2015 at 9:26 AM Yonik Seeley  wrote:

> I'm pleased to announce that Joel as accepted the PMC's invitation to join.
>
> Welcome Joel!
>
> -Yonik
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1003 - Still Failing

[david.w.smi...@gmail.com]

I created an issue: https://issues.apache.org/jira/browse/LUCENE-6873

On Sat, Oct 31, 2015 at 7:52 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1003/
>
> 1 tests failed.
> FAILED:
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.testRandom {#11
> seed=[D30126801503C858:4E8BBD0E05B60CEF]}
>
> Error Message:
> maxY must be >= minY: -23.184599227870876 to -23.18459922787088
>
> Stack Trace:
> com.spatial4j.core.exception.InvalidShapeException: maxY must be >= minY:
> -23.184599227870876 to -23.18459922787088
> at
> __randomizedtesting.SeedInfo.seed([D30126801503C858:4E8BBD0E05B60CEF]:0)
> at
> com.spatial4j.core.context.SpatialContext.makeRectangle(SpatialContext.java:218)
> at
> org.apache.lucene.spatial.SpatialTestCase.randomRectangle(SpatialTestCase.java:175)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.queryHeatmapRecursive(HeatmapFacetCounterTest.java:207)
> at
> org.apache.lucene.spatial.prefix.HeatmapFacetCounterTest.testRandom(HeatmapFacetCounterTest.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
> at
> 

Re: Welcome Nick Knize as Lucene/Solr committer

[david.w.smi...@gmail.com]

Welcome Nick!  We’re very fortunate to have your spatial expertise.
~ David

On Tue, Oct 20, 2015 at 1:40 PM Nicholas Knize  wrote:

> Thanks for the honor to join such a talented group!
>
> Brief Bio:  I started as a Meteorology major in undergrad. After the
> Meteorology program bored me with colored pencils and paper maps (but
> rocking a FORTRAN class) I switched to Computer Science. I received a CS
> Bachelor's and Master's focused on Computer Vision. Interestingly I was
> first exposed to Lucene/Solr in 2006 while working on a proprietary Remote
> Geospatial Imaging System. After a "fun" detour through the land of Oracle
> Spatial integration and MongoDB and Accumulo core development I finished a
> PhD in GIS focused on high dimension spatial Indexing. With sights set on
> working with the open source community I joined Elasticsearch 1 year ago
> this November which brings me here. I currently live in Dallas, TX with my
> Wife, 3 Kids, and a Dog and when my face is not behind a monitor I plant it
> either behind a drum kit, on a hockey rink, or in the park with the family.
>
> I look forward to continuing to virtually work with many of you and hope
> to meet many at conferences and meetups.
>
> Thanks again!
>
> - Nick
>
> On Tue, Oct 20, 2015 at 11:50 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> I'm pleased to announce that Nick Knize has accepted the PMC's
>> invitation to become a committer.
>>
>> Nick, it's tradition that you introduce yourself with a brief bio /
>> origin story, explaining how you arrived here.
>>
>> Your handle "nknize" has already added to the “lucene" LDAP group, so
>> you now have commit privileges.
>>
>> Please celebrate this rite of passage, and confirm that the right
>> karma has in fact enabled, by embarking on the challenge of adding
>> yourself to the committers section of the Who We Are page on the
>> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>> bookmarklet
>> at the bottom of the page here: https://cms.apache.org/#bookmark -
>> more info here http://www.apache.org/dev/cms.html).
>>
>> Congratulations and welcome!
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14285 - Still Failing!

[david.w.smi...@gmail.com]

Thanks! I'm not sure why I didn't find this in my testing.
On Wed, Sep 23, 2015 at 8:00 PM Anshum Gupta  wrote:

> I've fixed this on both trunk and 5x.
>
> On Wed, Sep 23, 2015 at 4:37 PM, Policeman Jenkins Server <
> jenk...@thetaphi.de> wrote:
>
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14285/
>> Java: 32bit/jdk1.8.0_60 -client -XX:+UseParallelGC
>>
>> All tests passed
>>
>> Build Log:
>> [...truncated 54728 lines...]
>> BUILD FAILED
>> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The
>> following error occurred while executing this line:
>> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:655: The
>> following error occurred while executing this line:
>> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:642: Source
>> checkout is dirty after running tests!!! Offending files:
>> * ./solr/licenses/spatial4j-0.4.1.jar.sha1
>>
>> Total time: 60 minutes 37 seconds
>> Build step 'Invoke Ant' marked build as failure
>> Archiving artifacts
>> [WARNINGS] Skipping publisher since build result is FAILURE
>> Recording test results
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13979 - Failure!

[david.w.smi...@gmail.com]

This is a duplicate of a known issue. Spatial4j 0.5 fixes this. I'll have a
patch for that later today.
On Mon, Sep 21, 2015 at 4:42 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13979/
> Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:
> org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations
> {#14 seed=[81259AC648C50EE8:492E44EF2E21F2EC]}
>
> Error Message:
> [Overlaps] qIdx:6 Should have matched I#2:Circle(Pt(x=37.0,y=-58.0),
> d=41.1° 4571.45km) Q:Circle(Pt(x=-143.0,y=58.0), d=69.5° 7724.04km)
>
> Stack Trace:
> java.lang.AssertionError: [Overlaps] qIdx:6 Should have matched
> I#2:Circle(Pt(x=37.0,y=-58.0), d=41.1° 4571.45km)
> Q:Circle(Pt(x=-143.0,y=58.0), d=69.5° 7724.04km)
> at
> __randomizedtesting.SeedInfo.seed([81259AC648C50EE8:492E44EF2E21F2EC]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
> at
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:121)
> at
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
> at
> org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations(CompositeStrategyTest.java:99)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> 

Re: LatLonType and wildcard ranges

[david.w.smi...@gmail.com]

Already filed long ago:
https://issues.apache.org/jira/browse/SOLR-3977

On Wed, Sep 16, 2015 at 11:58 AM Erick Erickson 
wrote:

> I get a parse error (looking at a user's list question) when trying to
> do something like:
> q=lat_lon_field:[* TO *], something like:
>
> INFO  - 2015-09-16 15:48:56.072; [   x:techproducts]
> org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/query
> params={q=*:*+-store:[*+TO+*]} status=500 QTime=2
> ERROR - 2015-09-16 15:48:56.073; [   x:techproducts]
> org.apache.solr.common.SolrException;
> null:java.lang.NullPointerException
> at java.lang.String.contains(String.java:2121)
> at
> org.apache.solr.util.SpatialUtils.parsePointSolrException(SpatialUtils.java:111)
> at org.apache.solr.schema.LatLonType.getRangeQuery(LatLonType.java:97)
> at
> org.apache.solr.parser.SolrQueryParserBase.getRangeQuery(SolrQueryParserBase.java:770)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:398)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:186)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:140)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:153)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:50)
> at org.apache.solr.search.QParser.getQuery(QParser.java:141)
>
> Of course you can do something like lat_lon_field_0_coordinate:[* TO
> *], but that's kind of arcane.
> Or use the trick of having a "has_lan_lon" field that you query on
> instead for this case...
>
> Worth a JIRA?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Switching AngularUI to default

[david.w.smi...@gmail.com]

With the old UI, I suggest doing something to the CSS to make it more
obvious you’re using the old UI… like changing the background color or
maybe instead of the CSS insert a label somewhere.  It’s very confusing to
switch and forget which one you’re using!

On Tue, Sep 15, 2015 at 5:11 AM Stefan Matheis  wrote:

> I'd go with (1); we took the same route for the current ui. otherwise
> people are still using the current one, until it's not available anymore -
> when they could have used the angular one already quite a while. at least
> that's my experience with that kind of changes :)
>
> -Stefan
>
> On Tuesday, September 15, 2015 at 10:59 AM, Upayavira wrote:
>
> The Angular UI for Solr is now feature complete, and people are asking
> that it be made the default. There are, undoubtedly, still bugs to be
> found in it.
>
> The new UI will have new features (e.g. a collections tab) so will
> hopefully be worth people using!
>
> Here's two options, as I see it, for 5.4:
>
> 1. Make it default, with a link back to the original UI in case of bugs
> 2. Add a link to the new UI to the current one (should have done that
> ages ago) in order to gather feedback before making it default
>
> Screenshots of links are here:
> https://issues.apache.org/jira/browse/SOLR-7858
>
> Thoughts?
>
> Upayavira
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Apache Lucene Update 2015-09-04

[david.w.smi...@gmail.com]

Thanks for this Mike :-)

On Fri, Sep 4, 2015 at 11:02 AM Michael McCandless  wrote:

> Lucene summary for this week:
>
>- A 5.3.1 bugfix release may be coming soon
>
>
>- See the confusion matrix
> for a classifier
>
>- Remove a nasty classloader hack that broke MorfologikFilter
>, and fix it
>correctly  so you
>can pass the dictionary as a URI
>
>- The new BoostQuery decouples Query from boosting
>, but it was
>missing its rewrite method
>
>
>- How can we compress postings payloads
>?
>
>- Nested conjunctions should always be flattened
>
>
>- MultiCollector did not handle early termination properly
>
>
>- Add a point-within-distance query
> implemented with
>BKD trees
>
>- Speed up IndexSearcher.count
>when a query is so
>simple (match all, single term) that we can use index statistics instead
>
>- The integration of BKDTree and Geo3D
>is done (for Lucene
>5.4.0), providing accurate and fast earth-surface "point in shape" queries,
>but we need to make its randomized tests more evil by simulating
>planets more squashed than earth
>, requiring somecrazy
>math
>
> ,
>including Lagrange multipliers
>
>
>- GeoPointDistanceQuery is buggy with large distances
>
>
>- Don't use approximations
> for
>MatchAllDocsQuery, and give it a dedicated BulkScorer
>
>
>- Dodge bugs in Java's collators
>
>
>- Windows NTFS pending delete state for a file
> causes assertion
>failures in Lucene; we should fix Lucene's WindowsFS to also simulate
>this state 
>
>- Symlinks to an index directory continue to cause problems for users
>
>
>- CheckIndex cannot handle corrupt .si
>files
>
>- Reduce heap used by
>
>CompressingStoredFieldsWriter when writing large strings during
>indexing
>
>- Reduce heap used by
> the new geo point
>queries by building the BytesRef on demand for sub-ranges
>
>- GeoPointDistanceRangeQuery will match points within a min/max
>distance range 
>
>- When you incorrectly index nested documents the resulting error
>messages are very confusing
>
>
>- DisjunctionMaxQuery, BoostingQuery and BoostedQuery now use
>IndexSearcher to create sub-weights
> so caching can
>apply
>
> Mike McCandless
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Remove woodstox-core-asl and stax2-api dependencies from Solr?

[david.w.smi...@gmail.com]

Yeah; Uwe’s story is also as I understand it.  IMO the dependencies aren’t
worth it unless someone demonstrably proves otherwise.  Given that SolJ
mostly uses javabin (response by default but not request; and requests tend
to be small), XML performance is less of an issue as well.
~ David

On Thu, Aug 27, 2015 at 8:31 AM Uwe Schindler u...@thetaphi.de wrote:

 Hi,



 There is not a direct dependency. The STAX-parser shipped with the JDK is
 too slow (said by some people). I am not sure if this is still true with
 Java 7 and Java 8, but In Java 6 it was! When having Woodstock in
 classpath, it plugs this XML parser into the JDK with SPI (like our lucene
 codecs). Solr should work without woodstox, but you may have slower XML
 imports (StAX is used by UpdateHandler#XMLLoader only).



 Uwe



 -

 Uwe Schindler

 H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de

 eMail: u...@thetaphi.de



 *From:* Varun Thacker [mailto:varunthacker1...@gmail.com]
 *Sent:* Thursday, August 27, 2015 1:41 PM
 *To:* dev@lucene.apache.org
 *Subject:* Remove woodstox-core-asl and stax2-api dependencies from Solr?



 I could not find any dependencies on these libraries. Did I miss anything
 or is it safe to remove them?



 --



 Regards,
 Varun Thacker

-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [VOTE] 5.3.0 RC2

[david.w.smi...@gmail.com]

+1
(Java 7)

SUCCESS! [1:02:40.331020]
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 57226 - Failure!

[david.w.smi...@gmail.com]

Added comment to existing issue LUCENE-6671.

On Sat, Jul 25, 2015 at 6:59 AM bu...@elastic.co wrote:

   *BUILD FAILURE*
 Build URL
 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/
 Project:lucene_linux_java8_64_test_only Randomization: 
 JDK8,local,heap[621m],-server
 +UseSerialGC +UseCompressedOops,sec manager on Date of build:Sat, 25 Jul
 2015 02:49:37 +0200 Build duration:9 min 35 sec
  *CHANGES* No Changes
  *BUILD ARTIFACTS*

-

 checkout/lucene/build/spatial/test/temp/junit4-J0-20150725_025856_578.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J0-20150725_025856_578.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J1-20150725_025856_579.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J1-20150725_025856_579.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J2-20150725_025856_579.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J2-20150725_025856_579.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J3-20150725_025856_579.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J3-20150725_025856_579.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J4-20150725_025856_579.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J4-20150725_025856_579.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J5-20150725_025856_579.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J5-20150725_025856_579.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J6-20150725_025856_580.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J6-20150725_025856_580.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J7-20150725_025856_580.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/artifact/checkout/lucene/build/spatial/test/temp/junit4-J7-20150725_025856_580.events


  *FAILED JUNIT TESTS* Name: org.apache.lucene.spatial.composite Failed: 1
 test(s), Passed: 19 test(s), Skipped: 0 test(s), Total: 20 test(s)


 * - Failed:
 org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations
 {#1 seed=[7A112ED39E509942:BC6C4FB9C63AD976]} *
  *CONSOLE OUTPUT* [...truncated 11258 lines...] [junit4]  [junit4]
 [junit4] JVM J0: 0.85 .. 9.05 = 8.20s [junit4] JVM J1: 0.86 .. 8.96 =
 8.10s [junit4] JVM J2: 1.09 .. 11.68 = 10.59s [junit4] JVM J3: 0.86 ..
 7.97 = 7.11s [junit4] JVM J4: 0.86 .. 11.93 = 11.07s [junit4] JVM J5:
 0.85 .. 11.75 = 10.90s [junit4] JVM J6: 0.86 .. 8.00 = 7.14s [junit4] JVM
 J7: 0.86 .. 11.02 = 10.16s [junit4] Execution time total: 11 seconds [junit4]
 Tests summary: 23 suites, 235 tests, 1 failure, 3 ignored (2 assumptions) 
 BUILD
 FAILED 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:470:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2243:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1447:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1002:
 There were test failures: 23 suites, 235 tests, 1 failure, 3 ignored (2
 assumptions) Total time: 9 minutes 14 seconds Build step 'Invoke Ant'
 marked build as failure Archiving artifacts Recording test results 
 [description-setter]
 Description set: JDK8,local,heap[621m],-server +UseSerialGC
 +UseCompressedOops,sec manager on Email was triggered for: Failure - 1st 
 Trigger
 Failure - Any was overridden by another trigger and will not send an email. 
 Trigger
 Failure - Still was overridden by another trigger and will not send an
 email. Sending email for trigger: Failure - 1st

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Christine Poerschke as Lucene/Solr committer

[david.w.smi...@gmail.com]

Welcome Christine!

~ David

On Fri, Jul 24, 2015 at 8:43 PM Christine Poerschke (BLOOMBERG/ LONDON) 
cpoersc...@bloomberg.net wrote:


 Thanks for the invitation and all the welcomes!

 super brief bio:
  * based in the UK (originally from Germany)
  * software developer in the News Search team at Bloomberg in London
 (joined
Bloomberg RD more than 10 years ago, directly after BSc and PhD time at
university)
  * hobby beekeeper and folding bike cyclist (not concurrently!)

 - Original Message -
 From: dev@lucene.apache.org
 To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
 At: Jul 24 2015 08:28:23

 I'm pleased to announce that Christine Poerschke has accepted the PMC's
 invitation to become a committer.

 Christine, it's tradition that you introduce yourself with a brief bio.

 Your account is not entirely ready yet. We will let you know when it is
 created
 and karma has been granted so that you can add yourself to the committers
 section of the Who We Are page on the website:
 http://lucene.apache.org/whoweare.html.

 Congratulations and welcome!

 --
 Adrien

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


 --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Mikhail Khludnev as Lucene/Solr committer

[david.w.smi...@gmail.com]

Welcome!  Well deserved Mikhail!

On Tue, Jul 21, 2015 at 10:24 AM Adrien Grand jpou...@gmail.com wrote:

 I'm pleased to announce that Mikhail Khludnev has accepted the PMC's
 invitation to become a committer.

 Mikhail, it's tradition that you introduce yourself with a brief bio.

 Your handle mkhl has already added to the “lucene LDAP group, so
 you now have commit privileges. Please test this by adding yourself to
 the committers section of the Who We Are page on the website:
 http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet
 at the bottom of the page here: https://cms.apache.org/#bookmark -
 more info here http://www.apache.org/dev/cms.html).

 Congratulations and welcome!

 --
 Adrien

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

 --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: ADDREPLICA and maxShardsPerNode and specifying a node

[david.w.smi...@gmail.com]

+1 to all Shai said.

On Thu, Jul 9, 2015 at 1:42 AM Shai Erera ser...@gmail.com wrote:

 I think that if addreplica is called, we should assume the user
 understands what he's doing, and we can safely ignore maxShardsPerNode.

 +1 in renaming it. I don't think it's late to do anything. First, it
 probably is an advanced parameter to be specified, if not expert. Second,
 we can always deprecate it and add maxReplicasPerNode, support both and
 remove the former in 2 minor releases  or the next major one.

 IMO it's more important to have good API with sensible parameter names,
 than leave it as that because of back-compat concerns.

 Shai
 On Jul 9, 2015 8:33 AM, Erick Erickson erickerick...@gmail.com wrote:

 I noticed today that if I create a collection with maxShardsPerNode, I
 can freely exceed that number by specifying the node parameter on an
 ADDREPLICA command.

 Is this intended behavior, or should I raise a JIRA? I can argue that
 if a user is really going to specify a node, then we should do
 whatever they say even if it exceeds maxShardsPerNode. If this is
 intended though I'll want to explicitly call that out in ref guide.

 Erick

 P.S. I'd _really_ like to rename maxShardsPerNode to
 maxReplicasPerNode, but it's too late for that.

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

  --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 54457 - Failure!

[david.w.smi...@gmail.com]

Ok, later tonight. I'm on vacation today.

On Mon, Jul 6, 2015 at 9:47 AM Michael McCandless luc...@mikemccandless.com
wrote:

 Hmm this could be LUCENE-6629?  Can you add a comment on the issue,
 copying the build failure stack trace, etc.?  Maybe it helps us get to the
 root cause of these weird hangs...


 Mike McCandless

 http://blog.mikemccandless.com

 On Sun, Jul 5, 2015 at 10:04 PM, david.w.smi...@gmail.com 
 david.w.smi...@gmail.com wrote:

 I’m not sure what to make of this.  The whole suite timed out after 2
 hours.  The seed doesn’t reproduce, at least when I ran via IntelliJ just
 this spatial test.  It’d be nice if I could have CI re-run the same build
 with same chosen random seed and JVM args, etc.

 On Sun, Jul 5, 2015 at 9:36 AM bu...@elastic.co wrote:

   *BUILD FAILURE*
 Build URL
 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/
 Project:lucene_linux_java8_64_test_only Randomization: 
 JDKEA9,network,heap[571m],-server
 +UseSerialGC +UseCompressedOops +AggressiveOpts,assert off,sec manager on 
 Date
 of build:Sun, 05 Jul 2015 13:23:16 +0200 Build duration:2 hr 8 min
  *CHANGES* No Changes
  *BUILD ARTIFACTS*

-

 checkout/lucene/build/spatial/test/temp/junit4-J0-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J0-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J1-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J1-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J2-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J2-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J3-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J3-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J4-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J4-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J5-20150705_133143_171.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J5-20150705_133143_171.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J6-20150705_133143_171.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J6-20150705_133143_171.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J7-20150705_133143_171.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J7-20150705_133143_171.events


  *FAILED JUNIT TESTS* Name: junit.framework Failed: 1 test(s), Passed:
 0 test(s), Skipped: 0 test(s), Total: 1 test(s)


 * - Failed:
 junit.framework.TestSuite.org.apache.lucene.spatial.bbox.TestBBoxStrategy * 
 Name:
 org.apache.lucene.spatial.bbox Failed: 1 test(s), Passed: 1 test(s),
 Skipped: 0 test(s), Total: 2 test(s)


 * - Failed:
 org.apache.lucene.spatial.bbox.TestBBoxStrategy.testCitiesIntersectsBBox *
  *CONSOLE OUTPUT* [...truncated 11575 lines...] [junit4]  [junit4]
 [junit4] JVM J0: 0.83 .. 9.63 = 8.80s [junit4] JVM J1: 1.07 .. 11.36 =
 10.28s [junit4] JVM J2: 0.91 .. 7224.92 = 7224.01s [junit4] JVM J3:
 1.08 .. 11.85 = 10.77s [junit4] JVM J4: 0.90 .. 8.82 = 7.93s [junit4]
 JVM J5: 0.87 .. 9.04 = 8.18s [junit4] JVM J6: 1.09 .. 11.50 = 10.41s 
 [junit4]
 JVM J7: 0.91 .. 10.98 = 10.07s [junit4] Execution time total: 2 hours
 24 seconds [junit4] Tests summary: 30 suites, 232 tests, 1 suite-level
 error, 1 error, 2 ignored (2 assumptions) BUILD FAILED 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:467:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2240:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
 There were test failures: 30 suites, 232 tests, 1 suite-level error, 1
 error, 2 ignored (2 assumptions) Total time

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 54457 - Failure!

[david.w.smi...@gmail.com]

I’m not sure what to make of this.  The whole suite timed out after 2
hours.  The seed doesn’t reproduce, at least when I ran via IntelliJ just
this spatial test.  It’d be nice if I could have CI re-run the same build
with same chosen random seed and JVM args, etc.

On Sun, Jul 5, 2015 at 9:36 AM bu...@elastic.co wrote:

   *BUILD FAILURE*
 Build URL
 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/
 Project:lucene_linux_java8_64_test_only Randomization: 
 JDKEA9,network,heap[571m],-server
 +UseSerialGC +UseCompressedOops +AggressiveOpts,assert off,sec manager on Date
 of build:Sun, 05 Jul 2015 13:23:16 +0200 Build duration:2 hr 8 min
  *CHANGES* No Changes
  *BUILD ARTIFACTS*

-

 checkout/lucene/build/spatial/test/temp/junit4-J0-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J0-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J1-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J1-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J2-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J2-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J3-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J3-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J4-20150705_133143_170.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J4-20150705_133143_170.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J5-20150705_133143_171.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J5-20150705_133143_171.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J6-20150705_133143_171.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J6-20150705_133143_171.events
-

 checkout/lucene/build/spatial/test/temp/junit4-J7-20150705_133143_171.events

 http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/54457/artifact/checkout/lucene/build/spatial/test/temp/junit4-J7-20150705_133143_171.events


  *FAILED JUNIT TESTS* Name: junit.framework Failed: 1 test(s), Passed: 0
 test(s), Skipped: 0 test(s), Total: 1 test(s)


 * - Failed:
 junit.framework.TestSuite.org.apache.lucene.spatial.bbox.TestBBoxStrategy * 
 Name:
 org.apache.lucene.spatial.bbox Failed: 1 test(s), Passed: 1 test(s),
 Skipped: 0 test(s), Total: 2 test(s)


 * - Failed:
 org.apache.lucene.spatial.bbox.TestBBoxStrategy.testCitiesIntersectsBBox *
  *CONSOLE OUTPUT* [...truncated 11575 lines...] [junit4]  [junit4]
 [junit4] JVM J0: 0.83 .. 9.63 = 8.80s [junit4] JVM J1: 1.07 .. 11.36 =
 10.28s [junit4] JVM J2: 0.91 .. 7224.92 = 7224.01s [junit4] JVM J3: 1.08
 .. 11.85 = 10.77s [junit4] JVM J4: 0.90 .. 8.82 = 7.93s [junit4] JVM J5:
 0.87 .. 9.04 = 8.18s [junit4] JVM J6: 1.09 .. 11.50 = 10.41s [junit4] JVM
 J7: 0.91 .. 10.98 = 10.07s [junit4] Execution time total: 2 hours 24
 seconds [junit4] Tests summary: 30 suites, 232 tests, 1 suite-level
 error, 1 error, 2 ignored (2 assumptions) BUILD FAILED 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:467:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2240:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
 There were test failures: 30 suites, 232 tests, 1 suite-level error, 1
 error, 2 ignored (2 assumptions) Total time: 128 minutes 38 seconds Build
 step 'Invoke Ant' marked build as failure Archiving artifacts Recording
 test results [description-setter] Description set:
 JDKEA9,network,heap[571m],-server +UseSerialGC +UseCompressedOops
 +AggressiveOpts,assert off,sec manager on Email was triggered for:
 Failure - 1st Trigger Failure - Any was overridden by another trigger and
 will not send an email. Trigger Failure - Still was overridden by another
 trigger and will not 

Re: solr 4.5 replicated slaves don't delete old files in /index directory

[david.w.smi...@gmail.com]

Ted,
Please ask again on the solr-user list; this list is for development of
Lucene/Solr.
Good luck,
~ David

On Tue, Jun 30, 2015 at 1:23 PM Ted Cao ted.cao.bos...@gmail.com wrote:

 Hi, I hope someone is aware of this bug and could point me to
 either
 old Jira ticket
 or advice on how it can be safely fixed ...

 In our production environment, with solr 4.5, we often see slave
 replicating down
 data from upstream into /index directory but NOT deleting older segment
 files ...

 We have enormous index, 1T+, so that adds to our problem, because we
 sometimes end up with 2T /index directory when fully optimized index is
 coming down ... the problem usually resolves itself in the next replication
 (or 2), but once we run out of disk, it gets in a vicious cycle

 Replicating this issue in dev/staging is very tricky so I hope someone
 knows this issue already.

 Possible solutions
 1. manually deleting old segment files (need to write some code and don't
 know if safe)
 2. would restart or issuing commits trigger deletion of the old files?

 Thanks, much appreciated!!!

Re: svn commit: r1688487 - in /lucene/cms/trunk/content/solr: assets/images/book_as3ess.jpg assets/images/book_asess_3ed.jpg assets/images/book_s14ess.jpg resources.mdtext

[david.w.smi...@gmail.com]

Ah; I see you fixed it already.  Thanks!

On Thu, Jul 2, 2015 at 7:18 PM david.w.smi...@gmail.com 
david.w.smi...@gmail.com wrote:

 Palm-to-face! I'll fix later today.
 On Thu, Jul 2, 2015 at 5:29 PM Chris Hostetter hossman_luc...@fucit.org
 wrote:


 Ummm, david ... i hate to tell you this, but it looks like you forgot the
 L in Solr in the title of your own book.

 more then once.

 :)

 : Mitchell](https://www.linkedin.com/in/mattmitchell4) are proud to
 : *finally* announce the book â??[Apache Sor Enterprise Search Server,

 ...

 : +a href=http://www.solrenterprisesearchserver.com;img alt=Apache
 : Sor Enterprise Search Server, Third Edition (cover) class=float-right


 -Hoss
 http://www.lucidworks.com/

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r1688487 - in /lucene/cms/trunk/content/solr: assets/images/book_as3ess.jpg assets/images/book_asess_3ed.jpg assets/images/book_s14ess.jpg resources.mdtext

[david.w.smi...@gmail.com]

Palm-to-face! I'll fix later today.
On Thu, Jul 2, 2015 at 5:29 PM Chris Hostetter hossman_luc...@fucit.org
wrote:


 Ummm, david ... i hate to tell you this, but it looks like you forgot the
 L in Solr in the title of your own book.

 more then once.

 :)

 : Mitchell](https://www.linkedin.com/in/mattmitchell4) are proud to
 : *finally* announce the book â??[Apache Sor Enterprise Search Server,

 ...

 : +a href=http://www.solrenterprisesearchserver.com;img alt=Apache
 : Sor Enterprise Search Server, Third Edition (cover) class=float-right


 -Hoss
 http://www.lucidworks.com/

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Version field as DV

[david.w.smi...@gmail.com]

I don’t know if it’s worth it in terms of the trade-offs, but there’s
something to be said about having *both* indexed=true  docValues=true on
the _version_ field in particular.  docValues is not an “index”; any
operation other than looking up the value for a specific document is
O(docs) with docValues.  VersionInfo.getMaxVersionFromIndex() has a slow
O(docs) algorithm when it has to use docValues, versus the field being
indexed=true which uses a O(log(versionCount)) where versionCount = docs.
It’s actually sometimes constant-time if the index postings format supports
ordinals (the default BlockTree one does not).  Maybe we should use an
ord-supported postings format.  What I don’t know is how frequent some of
these operations are on a version field, thus could better judge the
trade-offs.

~ David

On Mon, Jun 22, 2015 at 1:01 PM Chris Hostetter hossman_luc...@fucit.org
wrote:


 This thread kind of got off into a tangent about solr specifics -- if you
 skip down it's really a question about underlying performance concerns of
 using docvalues vs using stored fields.

 : 1.  _version_ never needs to be searchable, thus, indexed=false
 makes sense.

 Unless i'm wrong, the version field is involved in search contexts
 because of optimistic concurrency - in order for an updated doc=1 if
 version=42 then under the covers a search is done against hte version
 field --- but since this is a fairly constrained filter, indexed=false
 might still be fine as long as docValues=true because the search can be
 done via a DocValues based filter.

 : 4.  Given the above, is using docValues=true for _version_ a good
 idea?

 : My take is a simple “no”.  Since docValues is, in essence, column
 : oriented storage (and can be seen, I think, as an alternate index
 : format), what benefit is to be gained for the _version_ field.  The

 To be clear -- Solr already has code thta depends on having Doc Values
 on the version field to deal with max version value in segments (see
 VersionInfo.getVersionFromIndex and VersionInfo.getMaxVersionFromIndex) --
 but as with any field, that doens't mean you must have 'docValues=true'
 in your schema, instead the UninvertedReader can be used as long as the
 field is indexed.

 But that's really not what Ishan is asking about.

 We know it's possible to use docValues=true  indexed=false on the
 version field -- SOLR-6337 is open to decide if that makes sense in the
 sample configs.  Ishan's question is really about stored=false.

 The key bit of context of Ishan's question is updateable docValues
 (SOLR-5944) and if/how it might be usable in Solr for the version field --
 but one key aspect of doing that would be in ensuring that we can *return*
 the correct version value to user (for optimistic concurrency).  Currently
 that's done with stored fields, but that wouldn't be feasible if we go
 down hte route of updateable docValues, which means we would have to
 return the version field from the docValues.

 that's where ishan's question about docvalues and performance and disk
 seeks comes from...

 What are the downsides in saying instead of using docvalues and stored
 fields for this this single valued int per doc, we're only going to use
 docvalues  when doing pagination we will return the current value of the
 field to the user from the docvalues what kind of performance impacts
 come up in that case when you have 100 docs per page(ination)


 -Hoss
 http://www.lucidworks.com/

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Upayavira as Lucene/Solr committer

[david.w.smi...@gmail.com]

Welcome Upayavira!

On Mon, Jun 22, 2015 at 3:02 PM Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that Upayavira has accepted the PMC's invitation
 to become a committer.

 Upayavira, it's tradition that you introduce yourself with a brief bio.

 Mike McCandless, the Lucene PMC chair, has already added your “upayavira
 account to the “lucene LDAP group, so you now have commit privileges.
 Please test this by adding yourself to the committers section of the Who We
 Are page on the website: http://lucene.apache.org/whoweare.html (use
 the ASF CMS bookmarklet at the bottom of the page here: 
 https://cms.apache.org/#bookmark - more info here 
 http://www.apache.org/dev/cms.html).

 Congratulations and welcome!

 Steve
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Instructions on Solr's website about adding books

[david.w.smi...@gmail.com]

Solr’s “Resources” page, by the book section, contains this lead in text:
http://lucene.apache.org/solr/resources.html#solr-books

If you have a Solr book that you would like to see listed here, please
submit a patch http://wiki.apache.org/solr/HowToContribute via a JIRA
with the appropriate content.

“patch” is linked to: http://wiki.apache.org/solr/HowToContribute
What is not clear is where/what is the website that is to be patched. We
know where the Lucene/Solr code is but it’s not clear where this is.

I’ve updated the site before once for something, but it’s been so long that
I now forget how.  I have a CMS bookmarket but I don’t believe I’m supposed
to use that when a patch is involved — just for tiny edits.

~ David

Re: Looks like I broke Solr 5.2.0 - do we need a 5.2.1?

[david.w.smi...@gmail.com]

Yeah, I’ll port that too.

On Tue, Jun 9, 2015 at 12:36 PM Karl Wright daddy...@gmail.com wrote:

 There may be a prerequisite ticket fix that needs pulling up too?

 r1683532 | dsmiley | 2015-06-04 08:32:45 -0400 (Thu, 04 Jun 2015) | 1 line

 LUCENE-6520: Geo3D GeoPath.done() would throw an NPE if adjacent path
 segments w
 ere co-linear

 Karl

 On Tue, Jun 9, 2015 at 12:30 PM, david.w.smi...@gmail.com 
 david.w.smi...@gmail.com wrote:

 LUCENE-6535 is another one.

 On Tue, Jun 9, 2015 at 10:57 AM Shalin Shekhar Mangar 
 shalinman...@gmail.com wrote:

 Thanks Steve!

 On Tue, Jun 9, 2015 at 7:25 PM, Steve Rowe sar...@gmail.com wrote:


  On Jun 9, 2015, at 8:57 AM, Shalin Shekhar Mangar 
 shalinman...@gmail.com wrote:
 
  Looks like there are several small fixes that need to be added. I'll
 cut an RC tomorrow morning India time so that we have enough time to back
 port these items.
 
  I'll also setup a local Jenkins build for 5.2

 I’ll re-enable the ASF Jenkins 5.2 jobs now.

 Steve
 www.lucidworks.com
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




 --
 Regards,
 Shalin Shekhar Mangar.

Re: Looks like I broke Solr 5.2.0 - do we need a 5.2.1?

[david.w.smi...@gmail.com]

LUCENE-6535 is another one.

On Tue, Jun 9, 2015 at 10:57 AM Shalin Shekhar Mangar 
shalinman...@gmail.com wrote:

 Thanks Steve!

 On Tue, Jun 9, 2015 at 7:25 PM, Steve Rowe sar...@gmail.com wrote:


  On Jun 9, 2015, at 8:57 AM, Shalin Shekhar Mangar 
 shalinman...@gmail.com wrote:
 
  Looks like there are several small fixes that need to be added. I'll
 cut an RC tomorrow morning India time so that we have enough time to back
 port these items.
 
  I'll also setup a local Jenkins build for 5.2

 I’ll re-enable the ASF Jenkins 5.2 jobs now.

 Steve
 www.lucidworks.com
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




 --
 Regards,
 Shalin Shekhar Mangar.

Re: Looks like I broke Solr 5.2.0 - do we need a 5.2.1?

[david.w.smi...@gmail.com]

As mention in the JIRA ticket; this won’t be back-ported as it only applies
to the WGS84 feature added in 5.3.  Sorry for any confusion.

On Tue, Jun 9, 2015 at 12:42 PM david.w.smi...@gmail.com 
david.w.smi...@gmail.com wrote:

 Yeah, I’ll port that too.

 On Tue, Jun 9, 2015 at 12:36 PM Karl Wright daddy...@gmail.com wrote:

 There may be a prerequisite ticket fix that needs pulling up too?

 r1683532 | dsmiley | 2015-06-04 08:32:45 -0400 (Thu, 04 Jun 2015) | 1 line

 LUCENE-6520: Geo3D GeoPath.done() would throw an NPE if adjacent path
 segments w
 ere co-linear

 Karl

 On Tue, Jun 9, 2015 at 12:30 PM, david.w.smi...@gmail.com 
 david.w.smi...@gmail.com wrote:

 LUCENE-6535 is another one.

 On Tue, Jun 9, 2015 at 10:57 AM Shalin Shekhar Mangar 
 shalinman...@gmail.com wrote:

 Thanks Steve!

 On Tue, Jun 9, 2015 at 7:25 PM, Steve Rowe sar...@gmail.com wrote:


  On Jun 9, 2015, at 8:57 AM, Shalin Shekhar Mangar 
 shalinman...@gmail.com wrote:
 
  Looks like there are several small fixes that need to be added. I'll
 cut an RC tomorrow morning India time so that we have enough time to back
 port these items.
 
  I'll also setup a local Jenkins build for 5.2

 I’ll re-enable the ASF Jenkins 5.2 jobs now.

 Steve
 www.lucidworks.com
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




 --
 Regards,
 Shalin Shekhar Mangar.

Re: Looks like I broke Solr 5.2.0 - do we need a 5.2.1?

[david.w.smi...@gmail.com]

I’m +1 to this.  We can consider changing our mind once 5.3 is nocking on
the door if there are serious problems.

On Tue, Jun 9, 2015 at 2:36 PM Erick Erickson erickerick...@gmail.com
wrote:

 Upayavira:

 I'm a little reluctant to try to port the simpler patch to 5.2.1 as
 this is all new functionality. I can be argued into it though.

 It seems that the goal here is to get mileage out of the Angular JS
 port before making it the default. What do you (and others) think
 about changing 5.3 to use the angular JS by default for the admin UI?
 That'll drive lots of usage and help us solidify it for official
 release without trying to shoehorn a patch into 5.2.1 that's not
 critical to normal Solr/Lucene functioning.

 On Tue, Jun 9, 2015 at 9:42 AM, david.w.smi...@gmail.com
 david.w.smi...@gmail.com wrote:
  Yeah, I’ll port that too.
 
  On Tue, Jun 9, 2015 at 12:36 PM Karl Wright daddy...@gmail.com wrote:
 
  There may be a prerequisite ticket fix that needs pulling up too?
 
  r1683532 | dsmiley | 2015-06-04 08:32:45 -0400 (Thu, 04 Jun 2015) | 1
 line
 
  LUCENE-6520: Geo3D GeoPath.done() would throw an NPE if adjacent path
  segments w
  ere co-linear
 
  Karl
 
  On Tue, Jun 9, 2015 at 12:30 PM, david.w.smi...@gmail.com
  david.w.smi...@gmail.com wrote:
 
  LUCENE-6535 is another one.
 
  On Tue, Jun 9, 2015 at 10:57 AM Shalin Shekhar Mangar
  shalinman...@gmail.com wrote:
 
  Thanks Steve!
 
  On Tue, Jun 9, 2015 at 7:25 PM, Steve Rowe sar...@gmail.com wrote:
 
 
   On Jun 9, 2015, at 8:57 AM, Shalin Shekhar Mangar
   shalinman...@gmail.com wrote:
  
   Looks like there are several small fixes that need to be added.
 I'll
   cut an RC tomorrow morning India time so that we have enough time
 to back
   port these items.
  
   I'll also setup a local Jenkins build for 5.2
 
  I’ll re-enable the ASF Jenkins 5.2 jobs now.
 
  Steve
  www.lucidworks.com
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
  --
  Regards,
  Shalin Shekhar Mangar.
 
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Looks like I broke Solr 5.2.0 - do we need a 5.2.1?

[david.w.smi...@gmail.com]

A user found a nasty DefaultSolrHighlighter performance bug with an easy
fix — https://issues.apache.org/jira/browse/SOLR-7655  I’m running tests
now.

On Tue, Jun 9, 2015 at 2:48 PM david.w.smi...@gmail.com 
david.w.smi...@gmail.com wrote:

 I’m +1 to this.  We can consider changing our mind once 5.3 is nocking on
 the door if there are serious problems.

 On Tue, Jun 9, 2015 at 2:36 PM Erick Erickson erickerick...@gmail.com
 wrote:

 Upayavira:

 I'm a little reluctant to try to port the simpler patch to 5.2.1 as
 this is all new functionality. I can be argued into it though.

 It seems that the goal here is to get mileage out of the Angular JS
 port before making it the default. What do you (and others) think
 about changing 5.3 to use the angular JS by default for the admin UI?
 That'll drive lots of usage and help us solidify it for official
 release without trying to shoehorn a patch into 5.2.1 that's not
 critical to normal Solr/Lucene functioning.

 On Tue, Jun 9, 2015 at 9:42 AM, david.w.smi...@gmail.com
 david.w.smi...@gmail.com wrote:
  Yeah, I’ll port that too.
 
  On Tue, Jun 9, 2015 at 12:36 PM Karl Wright daddy...@gmail.com wrote:
 
  There may be a prerequisite ticket fix that needs pulling up too?
 
  r1683532 | dsmiley | 2015-06-04 08:32:45 -0400 (Thu, 04 Jun 2015) | 1
 line
 
  LUCENE-6520: Geo3D GeoPath.done() would throw an NPE if adjacent path
  segments w
  ere co-linear
 
  Karl
 
  On Tue, Jun 9, 2015 at 12:30 PM, david.w.smi...@gmail.com
  david.w.smi...@gmail.com wrote:
 
  LUCENE-6535 is another one.
 
  On Tue, Jun 9, 2015 at 10:57 AM Shalin Shekhar Mangar
  shalinman...@gmail.com wrote:
 
  Thanks Steve!
 
  On Tue, Jun 9, 2015 at 7:25 PM, Steve Rowe sar...@gmail.com wrote:
 
 
   On Jun 9, 2015, at 8:57 AM, Shalin Shekhar Mangar
   shalinman...@gmail.com wrote:
  
   Looks like there are several small fixes that need to be added.
 I'll
   cut an RC tomorrow morning India time so that we have enough time
 to back
   port these items.
  
   I'll also setup a local Jenkins build for 5.2
 
  I’ll re-enable the ASF Jenkins 5.2 jobs now.
 
  Steve
  www.lucidworks.com
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
  --
  Regards,
  Shalin Shekhar Mangar.
 
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 12789 - Failure!

[david.w.smi...@gmail.com]

Bug filed:
https://issues.apache.org/jira/browse/LUCENE-6535

On Sat, Jun 6, 2015 at 8:42 PM Policeman Jenkins Server jenk...@thetaphi.de
wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12789/
 Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC

 1 tests failed.
 FAILED:  org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations
 {#5 seed=[ADFCC7193C72FA89:9BDCDB8859624E4]}

 Error Message:
 [Intersects] qIdx:34 Shouldn't match
 I#1:Rect(minX=131.0,maxX=143.0,minY=39.0,maxY=54.0)
 Q:Geo3dShape{planetmodel=PlanetModel.SPHERE, shape=GeoPath:
 {planetmodel=PlanetModel.SPHERE, width=0.5061454830783556(29.0),
 points={[[X=0.5155270860898133, Y=-0.25143936017440033,
 Z=0.8191520442889918], [X=-6.047846824324981E-17, Y=9.57884834439237E-18,
 Z=-1.0], [X=-0.5677569555011356, Y=0.1521300177236823,
 Z=0.8090169943749475], [X=5.716531405282095E-17, Y=2.1943708116382607E-17,
 Z=-1.0]]}}}

 Stack Trace:
 java.lang.AssertionError: [Intersects] qIdx:34 Shouldn't match
 I#1:Rect(minX=131.0,maxX=143.0,minY=39.0,maxY=54.0)
 Q:Geo3dShape{planetmodel=PlanetModel.SPHERE, shape=GeoPath:
 {planetmodel=PlanetModel.SPHERE, width=0.5061454830783556(29.0),
 points={[[X=0.5155270860898133, Y=-0.25143936017440033,
 Z=0.8191520442889918], [X=-6.047846824324981E-17, Y=9.57884834439237E-18,
 Z=-1.0], [X=-0.5677569555011356, Y=0.1521300177236823,
 Z=0.8090169943749475], [X=5.716531405282095E-17, Y=2.1943708116382607E-17,
 Z=-1.0]]}}}
 at
 __randomizedtesting.SeedInfo.seed([ADFCC7193C72FA89:9BDCDB8859624E4]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:116)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:100)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
 at
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 12975 - Failure!

[david.w.smi...@gmail.com]

Ignore this; I'll fix the test Tuesday.
On Sun, Jun 7, 2015 at 11:36 AM Policeman Jenkins Server 
jenk...@thetaphi.de wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12975/
 Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC

 2 tests failed.
 FAILED:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeSphereModelRectRelationTest.testGeoBBoxRect

 Error Message:
 Did not find enough contains/within/intersection/disjoint/bounds cases in
 a reasonable number of random attempts. CWIDbD:
 5167(34),31(34),13688(34),1811(34),14199(34)  Laps exceeded 34896

 Stack Trace:
 java.lang.AssertionError: Did not find enough
 contains/within/intersection/disjoint/bounds cases in a reasonable number
 of random attempts. CWIDbD: 5167(34),31(34),13688(34),1811(34),14199(34)
 Laps exceeded 34896
 at
 __randomizedtesting.SeedInfo.seed([1F30D981250671ED:3B9571B901350FB3]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:96)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTestCase.testGeoBBoxRect(Geo3dShapeRectRelationTestCase.java:147)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:502)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:401)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)


 FAILED:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeWGS84ModelRectRelationTest.testGeoBBoxRect

 Error Message:
 Did not find enough contains/within/intersection/disjoint/bounds cases in
 a reasonable number of random attempts. CWIDbD:
 5167(34),31(34),13688(34),1811(34),14199(34)  Laps exceeded 34896

 Stack Trace:
 java.lang.AssertionError: Did not find enough
 contains/within/intersection/disjoint/bounds cases in a reasonable number
 of random attempts. CWIDbD: 5167(34),31(34),13688(34),1811(34),14199(34)
 Laps exceeded 34896
 at
 __randomizedtesting.SeedInfo.seed([1F30D981250671ED:3B9571B901350FB3]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:96)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTestCase.testGeoBBoxRect(Geo3dShapeRectRelationTestCase.java:147)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:502)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 

Re: TokenOrderingFilter

[david.w.smi...@gmail.com]

Hi Dmitry,

Ideally, the token stream produces tokens that have a startOffset = the
startOffset of the previous token from the stream.  Sometime in the past
year or so, this was enforced at the indexing layer, I think.  There used
to be TokenFilters that violated this contract; I think earlier versions of
WordDelimiterFilter could.  If my assumption that this is asserted at the
indexing layer is correct, then I think TokenOrderingFilter is obsolete.

~ David

On Thu, Jun 4, 2015 at 7:48 AM Dmitry Kan dmitry.luc...@gmail.com wrote:

Hi guys,

 Sorry for sending questions to the dev list and not to the user one.
 Somehow I'm getting more luck here.

 We have found the class o.a.solr.highlight.TokenOrderingFilter
 with the following comment:


 -/**

- * Orders Tokens in a window first by their startOffset ascending.

- * endOffset is currently ignored.

- * This is meant to work around fickleness in the highlighter only.  It

- * can mess up token positions and should not be used for indexing or 
 querying.

- */

-final class TokenOrderingFilter extends TokenFilter {

 In fact, removing this class didn't change the behaviour of the highlighter.

 Could anybody shed light on its necessity?

 Thanks,

 Dmitry Kan

Re: VOTE: RC0 release apache-solr-ref-guide-5.2.pdf

[david.w.smi...@gmail.com]

+1 looks good to me too.  I like some of the visual tweaks done to make the
formatting/theme similar to the website.

On Wed, Jun 3, 2015 at 5:07 PM Cassandra Targett casstarg...@gmail.com
wrote:

 +1, it looks good to me.

 Cassandra

 On Wed, Jun 3, 2015 at 12:30 PM, Chris Hostetter hossman_luc...@fucit.org
  wrote:


 Please VOTE to release these files as the Solr Ref Guide 5.2...


 https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.2-RC0/


 NOTE: this vote will be open for a minimum of 72 hours, but i will not
 call this (ref guide) vote to a close until the 5.2.0 code release is also
 successful -- just in case there are any last minute bugs found that
 warrant an update to the ref guide as well.



 -Hoss
 http://www.lucidworks.com/

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2377 - Failure!

[david.w.smi...@gmail.com]

Can you take a look Karl?
At first glance looking at the code, not running it, I’m guessing this is a
degenerate path segment that is too short.

On Tue, Jun 2, 2015 at 11:19 PM Policeman Jenkins Server 
jenk...@thetaphi.de wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2377/
 Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

 1 tests failed.
 FAILED:  org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations
 {#2 seed=[4AB0FA45EF43F0C3:2240DF3E6EDF83C]}

 Error Message:


 Stack Trace:
 java.lang.NullPointerException
 at
 __randomizedtesting.SeedInfo.seed([4AB0FA45EF43F0C3:2240DF3E6EDF83C]:0)
 at
 org.apache.lucene.spatial.spatial4j.geo3d.GeoPath$SegmentEndpoint.init(GeoPath.java:480)
 at
 org.apache.lucene.spatial.spatial4j.geo3d.GeoPath.done(GeoPath.java:121)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dRptTest.randomQueryShape(Geo3dRptTest.java:195)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:53)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:100)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
 at
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
 at
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at java.lang.Thread.run(Thread.java:745)




 Build Log:
 [...truncated 8066 lines...]

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 12734 - Failure!

[david.w.smi...@gmail.com]

Woops; I’ll fix.  This was a Java 8 / Java 7 issue.

On Tue, Jun 2, 2015 at 9:40 AM Policeman Jenkins Server jenk...@thetaphi.de
wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12734/
 Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC

 All tests passed

 Build Log:
 [...truncated 5634 lines...]
 [javac] Compiling 106 source files to
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/spatial/classes/java
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxSimilarityValueSource.java:52:
 warning: [rawtypes] found raw type: Map
 [javac]   public void createWeight(Map context, IndexSearcher
 searcher) throws IOException {
 [javac]^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxSimilarityValueSource.java:65:
 warning: [rawtypes] found raw type: Map
 [javac]   public FunctionValues getValues(Map context,
 LeafReaderContext readerContext) throws IOException {
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxValueSource.java:53:
 warning: [rawtypes] found raw type: Map
 [javac]   public FunctionValues getValues(Map context,
 LeafReaderContext readerContext) throws IOException {
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/serialized/SerializedDVStrategy.java:223:
 warning: [rawtypes] found raw type: Map
 [javac] public FunctionValues getValues(Map context,
 LeafReaderContext readerContext) throws IOException {
 [javac] ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/composite/CompositeVerifyQuery.java:92:
 warning: [rawtypes] found raw type: Map
 [javac] final Map valueSourceContext =
 ValueSource.newContext(searcher);
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/composite/IntersectsRPTVerifyQuery.java:89:
 warning: [rawtypes] found raw type: Map
 [javac] final Map valueSourceContext =
 ValueSource.newContext(searcher);
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/spatial4j/geo3d/PlanetModel.java:87:
 error: no suitable method found for hashCode(double)
 [javac] return Double.hashCode(ab) + Double.hashCode(c);
 [javac]  ^
 [javac] method Double.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac] method Object.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac]
 /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/spatial/src/java/org/apache/lucene/spatial/spatial4j/geo3d/PlanetModel.java:87:
 error: no suitable method found for hashCode(double)
 [javac] return Double.hashCode(ab) + Double.hashCode(c);
 [javac]^
 [javac] method Double.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac] method Object.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac]
 

Re: [JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_80) - Build # 4760 - Failure!

[david.w.smi...@gmail.com]

I fixed this already.

On Tue, Jun 2, 2015 at 10:10 AM Policeman Jenkins Server 
jenk...@thetaphi.de wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4760/
 Java: 32bit/jdk1.7.0_80 -server -XX:+UseConcMarkSweepGC

 All tests passed

 Build Log:
 [...truncated 5664 lines...]
 [javac] Compiling 106 source files to
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\spatial\classes\java
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\bbox\BBoxSimilarityValueSource.java:52:
 warning: [rawtypes] found raw type: Map
 [javac]   public void createWeight(Map context, IndexSearcher
 searcher) throws IOException {
 [javac]^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\bbox\BBoxSimilarityValueSource.java:65:
 warning: [rawtypes] found raw type: Map
 [javac]   public FunctionValues getValues(Map context,
 LeafReaderContext readerContext) throws IOException {
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\bbox\BBoxValueSource.java:53:
 warning: [rawtypes] found raw type: Map
 [javac]   public FunctionValues getValues(Map context,
 LeafReaderContext readerContext) throws IOException {
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\serialized\SerializedDVStrategy.java:223:
 warning: [rawtypes] found raw type: Map
 [javac] public FunctionValues getValues(Map context,
 LeafReaderContext readerContext) throws IOException {
 [javac] ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\composite\CompositeVerifyQuery.java:92:
 warning: [rawtypes] found raw type: Map
 [javac] final Map valueSourceContext =
 ValueSource.newContext(searcher);
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\composite\IntersectsRPTVerifyQuery.java:89:
 warning: [rawtypes] found raw type: Map
 [javac] final Map valueSourceContext =
 ValueSource.newContext(searcher);
 [javac]   ^
 [javac]   missing type arguments for generic class MapK,V
 [javac]   where K,V are type-variables:
 [javac] K extends Object declared in interface Map
 [javac] V extends Object declared in interface Map
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\spatial4j\geo3d\PlanetModel.java:87:
 error: no suitable method found for hashCode(double)
 [javac] return Double.hashCode(ab) + Double.hashCode(c);
 [javac]  ^
 [javac] method Double.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac] method Object.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac]
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\spatial\src\java\org\apache\lucene\spatial\spatial4j\geo3d\PlanetModel.java:87:
 error: no suitable method found for hashCode(double)
 [javac] return Double.hashCode(ab) + Double.hashCode(c);
 [javac]^
 [javac] method Double.hashCode() is not applicable
 [javac]   (actual and formal argument lists differ in length)
 [javac] method Object.hashCode() is not applicable
 [javac]   (actual and formal argument 

Re: Moving to git?

[david.w.smi...@gmail.com]

Nice!

On Sun, May 31, 2015 at 1:31 PM Steve Davids sdav...@gmail.com wrote:

 bq. Something needs to be done about all those jars in the source
 history, I will not let this go.

 I went ahead and used the BFG Repo Cleaner
 https://rtyley.github.io/bfg-repo-cleaner/ tool to drop all of the old
 jars in the git history, here are the findings:

 $ git clone --mirror https://github.com/apache/lucene-solr.git
 lucene-solr-mirror

  489M lucene-solr-mirror

 $ java -jar ~/Downloads/bfg-1.12.3.jar --delete-files *.jar
 --protect-blobs-from trunk,branch_5x,branch_4x lucene-solr-mirror
 $ cd lucene-solr-mirror
 $ git reflog expire --expire=now --all  git gc --prune=now --aggressive

  182M lucene-solr-mirror

 $ cat lucene-solr-mirror.bfg-report/2015-05-31/10-16-36/deleted-files.txt
 af4eed0506b53f17a4d22e4f1630ee03cb7991e5 177868 Tidy.jar
 53f82a1c4c492dc810c27317857bbb02afd6fa58 62983 activation-1.1.jar
 3beb3b802ffd7502ac4b4d47e0b2a75d08e30cc3 1034049 ant-1.6.5.jar
 704717779f6d0d7eb026dc7af78a35e51adeec8b 1323005 ant-1.7.1.jar
 7f5be4a4e05939429353a90e882846aeac72b976 1933743 ant-1.8.2.jar
 063cce4f940033fa6e33d3e590cf6f5051129295 93518 ant-junit-1.7.1.jar
 704717779f6d0d7eb026dc7af78a35e51adeec8b 1323005 apache-ant-1.7.1.jar
 063cce4f940033fa6e33d3e590cf6f5051129295 93518 apache-ant-junit-1.7.1.jar
 e3c62523fb93b5e2f73365e6cee0d0bc68e48556 95511 apache-mime4j-core-0.7.jar
 1f7bf1ea13697ca0243d399ca6e5d864dd8bec0b 300168 apache-mime4j-dom-0.7.jar
 bab8b31fb99256e13fc6010701db560243c47fa7 26027
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar
 5c4007c7e74af85d823243153d308f80e084eff0 22478
 apache-solr-noggit-r1099557.jar
 f59a39b011591edafc7955e97ae0d195fdf8b42e 22376
 apache-solr-noggit-r1209632.jar
 2a07c61d9ecb9683a135b7847682e7c36f19bbfe 22770
 apache-solr-noggit-r1211150.jar
 30be80e0b838a9c1445936b6966ccfc7ff165ae5 36776
 apache-solr-noggit-r730138.jar
 97d779912d38d2524a0e20efa849a4b6f01a4b46 21229
 apache-solr-noggit-r730138.jar
 a798b805d0ce92606697cc1b2aac42bf416076e3 37259
 apache-solr-noggit-r944541.jar
 9b434f5760dd0d78350bdf8237273c0d5db0174e 21240
 apache-solr-noggit-r944541.jar
 8217cae0a1bc977b241e0c8517cc2e3e7cede276 43033 asm-3.1.jar
 4133d823d96bf3fc26d3a9754375dcc30d8da416 342664 asm-debug-all-4.1.jar
 f66e9a8b9868226121961c13e6a32a55d0b2f78a 229116 bcmail-jdk15-1.45.jar
 409070b0370a95c14ed4357261afb96b91d10e86 1663318 bcprov-jdk15-1.45.jar
 b64b033af70609338c07e2a88a5f7efcd1a84ddb 92027 boilerpipe-1.1.0.jar
 96c3bdbdaacd5289b0e654842e435689fbcf22e2 679423 carrot2-core-3.4.0.jar
 043c0cb889aea066f7d4126af029d00a0bcd9e81 655412 carrot2-core-3.4.0.jar
 f872cbc8eec94f7d5b29a73f99cd13089848a3cd 933657 carrot2-core-3.4.2.jar
 ce2d3bf9c28a4ff696d66a82334d15fd0161e890 995243 carrot2-core-3.4.2.jar
 be94db93d41bd4ba53b650d421cfa5fb0519b9af 958799 carrot2-core-3.5.0.1.jar
 adc127c48137d03e252f526de84a07c8d6bda521 979186 carrot2-core-3.5.0.jar
 ab44cf9314b1efff393e05f9c938446887d3570e 981085 carrot2-core-3.5.0.jar
 5ca86c5e72b2953feb0b58fbd87f76d0301cbbf6 517641 carrot2-mini-3.1.0.jar
 b1b89c9c921f16af22a88db3ff28975a8e40d886 188671 commons-beanutils-1.7.0.jar
 e633afbe6842aa92b1a8f0ff3f5b8c0e3283961b 36174 commons-cli-1.1.jar
 957b6752af9a60c1bb2a4f65db0e90e5ce00f521 46725 commons-codec-1.3.jar
 458d432da88b0efeab640c229903fb5aad274044 58160 commons-codec-1.4.jar
 e9013fed78f333c928ff7f828948b91fcb5a92b4 73098 commons-codec-1.5.jar
 ee1bc49acae11cc79eceec51f7be785590e99fd8 232771 commons-codec-1.6.jar
 41e230feeaa53618b6ac5f8d11792c2eecf4d4fd 559366 commons-collections-3.1.jar
 c35fa1fee145cba638884e41b80a401cbe4924ef 575389
 commons-collections-3.2.1.jar
 78d832c11c42023d4bc12077a1d9b7b5025217bc 143847 commons-compress-1.0.jar
 51baf91a2df10184a8cca5cb43f11418576743a1 161361 commons-compress-1.1.jar
 61753909c3f32306bf60d09e5345d47058ba2122 168596 commons-compress-1.2.jar
 6c826c528b60bb1b25e9053b7f4c920292f6c343 224548 commons-compress-1.3.jar
 f80348dfa0b59f0840c25d1b8c25d1490d1eaf51 22017
 commons-csv-1.0-SNAPSHOT-r609327.jar
 8439e6f1a8b1d82943f84688b8086869255eda86 27361
 commons-csv-1.0-SNAPSHOT-r966014.jar
 1783dbea232ced6db122268f8faa5ce773c7ea42 139966 commons-digester-1.7.jar
 9c8bd13a2002a9ff5b35b873b9f111d5281ad201 148783 commons-digester-2.0.jar
 aa209b3887c90933cdc58c8c8572e90435e8e48d 57779 commons-fileupload-1.2.1.jar
 7c59774aed4f5dd08778489aaad565690ff7c132 305001 commons-httpclient-3.1.jar
 133dc6cb35f5ca2c5920fd0933a557c2def88680 109043 commons-io-1.4.jar
 b5c7d692fe5616af4332c1a1db6efd23e3ff881b 163151 commons-io-2.1.jar
 ce0ca22c8d29a9be736d775fe50bfdc6ce770186 257923 commons-lang-2.4.jar
 532939ecab6b77ccb77af3635c55ff9752b70ab7 261809 commons-lang-2.4.jar
 98467d3a653ebad776ffa3542efeb9732fe0b482 284220 commons-lang-2.6.jar
 b73a80fab641131e6fbe3ae833549efb3c540d17 38015 commons-logging-1.0.4.jar
 1deef144cb17ed2c11c6cdcdcb2d9530fa8d0b47 60686 commons-logging-1.1.1.jar
 ae0b63586701efdc7bf03ffb0a840d50950d211c 3566844 core-3.1.1.jar
 

Re: Moving to git?

[david.w.smi...@gmail.com]

I like where this is going!

I also think history of source code is very important, but not history of
‘.jar’ files that shouldn’t have been in source control in the first
place.  I’m fiercely negative about large binaries or ‘jar’ files that can
be downloaded by the build system (e.g. ivy) in source control.  And it was
already mentioned a full history (.jar’s  all) could be kept somewhere
more for archival purposes — which is a good compromise, I think, since
“build-ability” of history should be retained (assuming it’s even still
possible, given Rob’s comments) but doesn’t have to be convenient (e.g. by
it being in a separate repo).   +1 to that!

If we were to come up with a new git repo that doesn’t have the ‘.jar’s,
it’d be good to also streamline the history prior to the big Lucene + Solr
merge due to the paths in source control as to where the trunk, branches,
and tags lived.  It appears the current repo may have been a blind git
import from subversion.  And hand-done process that is mindful of these
things would result in a nice history.  I’ve done this sorta thing once (a
project at my last job) and volunteer to do it here if we can get consensus
on a move to git.

~ David

On Sun, May 31, 2015 at 4:21 PM Dawid Weiss dawid.we...@cs.put.poznan.pl
wrote:

  I'd like to have full consolidated history, as much as possible,
  connect-the-dots across whatever CVS/SVN/etc repos to the extent
  maximally permitted by law, as Doug hints at. Just nuke the jars.

 I've done this (CVS-SVN-GIT) before. It wasn't that difficult.
 Eventually (for git) you script it and it gets version after version
 from CVS or SVN and appends it to git. I admit I didn't care much
 about svn merging infos though. Any files can be removed/ pruned by
 rewriting git trees before they're published.

 Dawid

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Moving to git?

[david.w.smi...@gmail.com]

Hmmm.  I pulled up this file in IntelliJ in my git checkout and viewed the
history.  It went back to March 17th 2010 (earlier than the 2012 you found)
with git hash 3ee0ace1ba6b9bff3ffaa278c0bba07e6064057dwith a commit
message of:
git-svn-id:
https://svn.apache.org/repos/asf/lucene/solr/branches/newtrunk@924483
13f79535-47bb-0310-9956-ffa450edef68
All files were added in that commit; it's the earliest commit in this git
repo.  This is the kind of thing I should be able to fix if I build a repo
manually.

Side note: I used to be able to see the commands IntelliJ gave to git, but
I don’t see it in the latest EAP anyways.  I was wondering if it passed the
an option to git log like --find-renames=40% to be more aggressive in its
rename detection.

On Sun, May 31, 2015 at 6:57 PM Robert Muir rcm...@gmail.com wrote:

 And here is IndexWriter with initial revision in 2001, but again git
 still only stops at Feb 7, 2012.

 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java?view=log

 Revision 149570 - (view) (download) (annotate) - [select for diffs]
 Added Tue Sep 18 16:29:48 2001 UTC (13 years, 8 months ago) by jvanzyl
 Original Path:
 lucene/java/trunk/src/java/org/apache/lucene/index/IndexWriter.java
 File length: 15076 byte(s)

 Initial revision

 So subversion history looks pretty complete. If we can add other
 history from sourceforge, fantastic, but there isn't so so much going
 on there.

 It is git that is totally broken here with respect to history.


 On Sun, May 31, 2015 at 6:47 PM, Robert Muir rcm...@gmail.com wrote:
  On Sun, May 31, 2015 at 4:39 PM, david.w.smi...@gmail.com
  david.w.smi...@gmail.com wrote:
 
  If we were to come up with a new git repo that doesn’t have the ‘.jar’s,
  it’d be good to also streamline the history prior to the big Lucene +
 Solr
  merge due to the paths in source control as to where the trunk,
 branches,
  and tags lived.  It appears the current repo may have been a blind git
  import from subversion.  And hand-done process that is mindful of these
  things would result in a nice history.  I’ve done this sorta thing once
 (a
  project at my last job) and volunteer to do it here if we can get
 consensus
  on a move to git.
 
  The current Git history is totally broken. This is a complete
  dealbreaker from my perspective, if its indicative of what svn - git
  conversion will produce.
 
  Look at CheckIndex.java history in git:
 
 
 https://github.com/apache/lucene-solr/commits/trunk/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java?page=5
  It stops at Feb 7, 2012.
 
  In subversion it goes back to 2007, to the original issue where Mike
  added CheckIndex:
 
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java?view=log

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] 5.2.0 RC2

[david.w.smi...@gmail.com]

It’d be nice if something like that failed the build.  There’s kind of a
soft  dependency there for Solr’s logging admin screen, which is optional.

~ David

On Sun, May 31, 2015 at 12:45 AM Tomás Fernández Löbbe 
tomasflo...@gmail.com wrote:

 Unfortunately I imported log4j Logger instead of slf4j in SOLR-7406. I'll
 fix this and merge it in the 5.2 branch. I think this should be a blocker
 since it would require people to have the log4j jars.

 On Fri, May 29, 2015 at 4:04 PM, Timothy Potter thelabd...@gmail.com
 wrote:

 +1 SUCCESS! [0:53:16.298079]

 Woots!

 On Fri, May 29, 2015 at 7:30 AM, Ishan Chattopadhyaya
 ichattopadhy...@gmail.com wrote:
  +1
  SUCCESS! [1:53:58.019931]
 
  (A cloudatcost.com, one time, $500 8GB ram VPS here)
 
  On Fri, May 29, 2015 at 6:59 PM, Mark Miller markrmil...@gmail.com
 wrote:
 
  bq. SUCCESS! [0:22:46.736047]
 
  That is just absurd.
 
  +1
 
  SUCCESS! [0:45:01.183084]
 
  - Mark
 
 
  On Fri, May 29, 2015 at 9:20 AM Steve Rowe sar...@gmail.com wrote:
 
  +1
 
  SUCCESS! [0:22:46.736047]
 
  I first downloaded via Subversion (took ~9 min), then pointed the
 smoke
  tester at the checkout:
 
  cd /tmp
  svn co
 
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.2.0-RC2-rev1682356
  cd ~/svn/lucene/dev/branches/lucene_solr_5_2
  python3 -u dev-tools/scripts/smokeTestRelease.py
  file:///tmp/lucene-solr-5.2.0-RC2-rev1682356/
 
  Steve
 
   On May 29, 2015, at 1:14 AM, Anshum Gupta ans...@anshumgupta.net
   wrote:
  
   Please vote for the second release candidate for Apache Lucene/Solr
   5.2.0.
  
   The artifacts can be downloaded from:
  
  
  
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.2.0-RC2-rev1682356
  
   You can run the smoke tester directly with this command:
  
   python3 -u dev-tools/scripts/smokeTestRelease.py
  
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.2.0-RC2-rev1682356/
  
   Here's my +1
  
   SUCCESS! [0:31:06.632891]
  
   --
   Anshum Gupta
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Moving to git?

[david.w.smi...@gmail.com]

+1 to git.  Git may not be perfect, but SVN isn’t either.

On Fri, May 29, 2015 at 11:59 PM Ishan Chattopadhyaya 
ichattopadhy...@gmail.com wrote:

 Life is so much easier on long train/plane journeys with Git. +1.

 On Sat, May 30, 2015 at 9:21 AM, Shai Erera ser...@gmail.com wrote:

 +1 to moving to git.

 Shai
 On May 30, 2015 6:24 AM, Anshum Gupta ans...@anshumgupta.net wrote:

 * There may be other good reasons for using git, but this is not one.*
 I just added one more to the list. I think most other reasons have
 already been spoken about in previous discussions. I'm not trying to debate
 on what is better (I think it's a lot to do with *opinion*).

 I think it's a reasonable thing to move to a system that allows for
 distributed version control and makes working on multiple things at the
 same time easy. But again, that's my thought. The last time the discussion
 came up, I was +1 to moving and wasn't already using it a lot. Right now,
 I'm just trying to work on multiple things and find git easier for that
 purpose.

 I just wanted to bring this back up and see if the opinion of active
 contributors has changed since the last time by means of a polite and
 friendly discussion. In the end, we can agree to disagree but it'd be
 better than not discussing at all. :-)


 On Fri, May 29, 2015 at 7:24 PM, Walter Underwood wun...@wunderwood.org
  wrote:

 There may be other good reasons for using git, but this is not one.

 wunder
 Walter Underwood
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)

 On May 29, 2015, at 6:57 PM, Yonik Seeley ysee...@gmail.com wrote:

 On Fri, May 29, 2015 at 9:40 PM, Walter Underwood 
 wun...@wunderwood.org wrote:

 “git breaks when it tries to mirror” is not a convincing argument for
 moving
 to git.


 I'd be +1 without that annoyance as well.  As Anshum mentioned, this
 has come up a number of times in the past.

 -Yonik

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org





 --
 Anshum Gupta

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build # 12825 - Failure!

[david.w.smi...@gmail.com]

This is not a real bug; it’s the test asserting it finds a minimum number
relation types over many random shapes… but that can sometimes be asking
too much.  I filed an issue to improve, which I’ll get to shortly:
LUCENE-6502 - Spatial RectIntersectionTestHelper should only require one of
each relation type to complete
https://issues.apache.org/jira/browse/LUCENE-6502

On Tue, May 26, 2015 at 3:37 AM Policeman Jenkins Server 
jenk...@thetaphi.de wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12825/
 Java: 64bit/jdk1.8.0_45 -XX:-UseCompressedOops -XX:+UseParallelGC

 1 tests failed.
 FAILED:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect

 Error Message:
 Did not find enough contains/within/intersection/disjoint/bounds cases in
 a reasonable number of random attempts. CWIDbD:
 3235(22),20(22),8927(22),1129(22),9315(22)  Laps exceeded 22626

 Stack Trace:
 java.lang.AssertionError: Did not find enough
 contains/within/intersection/disjoint/bounds cases in a reasonable number
 of random attempts. CWIDbD: 3235(22),20(22),8927(22),1129(22),9315(22)
 Laps exceeded 22626
 at
 __randomizedtesting.SeedInfo.seed([20CB0E5500D415D2:46EA66D24E76B8C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:96)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:145)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:401)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)




 Build Log:
 [...truncated 8160 lines...]
[junit4] Suite:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest
[junit4]   1 Laps: 23218 CWIDbD: 11893,51,5896,1732,3646
[junit4]   1 Laps: 1560 CWIDbD: 140,3,632,304,481
[junit4] FAILURE 1.46s J0 | Geo3dShapeRectRelationTest.testGeoBBoxRect
 
[junit4] Throwable #1: java.lang.AssertionError: Did not find
 enough contains/within/intersection/disjoint/bounds cases in a reasonable
 number of random attempts. CWIDbD:
 3235(22),20(22),8927(22),1129(22),9315(22)  Laps exceeded 22626
[junit4]at
 __randomizedtesting.SeedInfo.seed([20CB0E5500D415D2:46EA66D24E76B8C]:0)
[junit4]at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:96)
[junit4]at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:145)
[junit4]   1 Laps: 16334 CWIDbD: 4216,8,7024,2976,2110
[junit4] Completed [26/28] on J0 in 4.68s, 6 tests, 1 failure 
 FAILURES!

 [...truncated 17 lines...]
 BUILD FAILED
 /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The
 following error 

Re: official ASF Jenkins Slave moved to Ubuntu 14.04

[david.w.smi...@gmail.com]

Thanks for your hard work on keeping Lucene/Solr well tested!

On Fri, May 22, 2015 at 5:23 PM Uwe Schindler u...@thetaphi.de wrote:

 Hi all,

 the old lucene-zones.apache.org machine, running on FreeBSD, was disabled
 an hour ago and all Jobs migrated. This old machine was not able to run
 Java 8 at all (crushed all the time and had the famous FreeBSD blackhole).
 In addition, it was about to be decommissioned soon; we moved the whole
 slave to a Ubuntu 14.04 machine.

 From now on all builds are running in a VMware machine (
 lucene1-us-west.apache.org) running Ubuntu 14.04 with 4 (virtual) cores
 [/proc/cpuinfo says: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz] and 16 GiB
 of RAM.

 I changed all jobs to use the correct JDK version (because those are
 installed automatically now) - sorry for the mail flood about broken jobs.
 I hope all is fine now, if you find a problem, please respond to this mail
 with Jenkins Job and build number. Possible errors could be files not found
 (nightly jobs using Wikipedia dumps, Maven upload to snapshot repo not
 working, or cases where I missed to change JDK version).

 I will now cleanup the policy file of test security to no longer have the
 hardcoded FreeBSD localhost address workaround with hardcoded hostname
 (will just heavy commit).

 Uwe

 P.S.: Thanks to Chris Lambertus and Gavin McDonald for their help during
 the migration.

 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!

[david.w.smi...@gmail.com]

For a long while on my local checkout, I have svn:ignore at the root level
set to ‘*’.  I really think we should consider committing this; I think
I’ve advocated for it before.

RE “precommit” being a pain — yeah but, like Mike already said, it catches
problems.  At least it’s faster lately than it used to be months ago.

On Thu, May 21, 2015 at 5:16 AM Michael McCandless 
luc...@mikemccandless.com wrote:

 On Wed, May 20, 2015 at 11:38 PM, Yonik Seeley ysee...@gmail.com wrote:
  Seems like a bug in javadoc if it fails on valid java code with no
  javadoc specified on the involved classes.
 
  if you'd run ant precommit you would have gotten the same error, and
  (if you hadn't understood the problem) you could have asked about it
  before breaking the build.
 
  I normally only make sure unit tests pass.

 Please understand that by taking this attitude you waste everyone
 else's time who does want to pass ant precommit before committing,
 and everyone else's time to scan all these broken builds emails.

 If you truly refuse to pass ant precommit before committing, at
 least be vigilant and watch the next few builds to see if you broke
 them, and then fix it quickly.

  ant precommit is way to picky.

 I agree it's picky but I think that's a feature, not a bug :)

 It is this way so it catches common errors that unit tests don't
 catch: a leftover #nocommit, wrong svn props, forgot to svn add, etc.
 Over time we've made it more picky each time one of us falls into a
 trap of forgetting to do XYZ before committing.

 And in this case it looks like it caught something truly wrong with
 your change (a public API using a package-private class).  Had you run
 it before hand and paid attention to what it said you could have fixed
 it...

 My biggest complaint is how slow it is ... I wish we could improve that.

  For example it will fail if one as
  any extra files lying around (which is normally the case for active
  development / debugging).  Doing a clean checkout and re-applying the
  patch just to make ant precommit happy is too high of a hurdle.  My
  guess is that most committers don't use it for the majority of
  commits.

 This is to try to help you remember to svn add files.  Why not store
 such files outside of the source tree?  Or maybe we can add them to
 svn:ignore?

 Mike McCandless

 http://blog.mikemccandless.com

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

TermsQuery in ‘join’ module redundant?

[david.w.smi...@gmail.com]

Today I noticed org.apache.lucene.search.join.TermsQuery (package access)
in the join module that is functionally equivalent to one by the same name
in the queries module.  It may be a bit historical since the one in the
queries module until recently was a Filter, not a Query.  But now there is
redundancy.  Based on recent changes in Lucene 5.2 done by Adrien to
TermsQuery; I suspect both implementations would perform about the same.
Thus, I think the one in the ‘join’ module should be deleted.

Note the ‘join’ module does not yet depends on the ‘queries’ module. I
think the TermsQuery is of such broad general utility that it should go
into Lucene core.

~ David

Re: Configsets and Config APIs in Solr

[david.w.smi...@gmail.com]

+1 Tomas.

On Fri, May 15, 2015 at 12:40 PM Tomás Fernández Löbbe 
tomasflo...@gmail.com wrote:

 I agree about differentiating the mutable part (configoverlay, generated
 schema, etc) and the immutable (the configset) , but I think it would be
 better if the mutable part is placed under /collections/x/..., otherwise
 /configs would have a mix of ConfigSets and collection-specific
 configuration.

 On Fri, May 15, 2015 at 6:38 AM, Noble Paul noble.p...@gmail.com wrote:

 I think this needs more discussion

 When a collection is created we should have two things

 an immutable part and a mutable part

 for instance my collection name is x and it uses schemaless example conf

 I must now have two conf dirs

 configs/schemaless and
 configs/x

 all the mutable stuff goes to configs/x

 and config/schemaless remains immutable



 On Tue, May 12, 2015 at 2:23 AM, Tomás Fernández Löbbe 
 tomasflo...@gmail.com wrote:

 I think this is fine.I don't think we need a new concept of config
 templates, we just need to make it clear that the configset used to create
 the collection is not modified by Solr, and that any change done via API
 only affects the single collection where the config command is issued.

 I guess the schema API should start using something like configoverlay,
 or maybe persist the updated schema to this new path?

 Tomás

 On Fri, May 8, 2015 at 10:28 PM, Noble Paul noble.p...@gmail.com
 wrote:

 I agree with you on the point that it causes confusion.

 My suggestion would be to have something called config templates and
 they are immutable . So , we don't need a configset API
 each collection have it's own conf folder .

 So, when a collection is created we should go ahead and create a
 corresponding conf dir.

 Ideally, it should not copy over all configs from it's template. It
 should just store the configoverlay.json, params.json in the collection's
 conf directory and inherit the rest from the template





 On Sat, May 9, 2015 at 9:35 AM, Tomás Fernández Löbbe 
 tomasflo...@gmail.com wrote:

 I think the concept of ConfigSets has become a bit confusing with the
 Config APIs (I'm thinking in SolrCloud mode here). Solr requires that a
 configset is pushed to ZooKeeper before creating a collection that uses 
 it.
 It supports multiple collections using the same configset, which I think 
 is
 great. You could also have a couple of configsets that no collection is
 currently using (who knows, maybe one that was recently deprecated, or 
 that
 will be used soon, etc). This gives me the idea that configsets are a
 separate entity than the collection, not just a collection's 
 configuration.

 Config APIs allow you to operate on a collection to add handlers,
 change settings, etc. The problem is that you are not really applying the
 changes to the collection but to the complete configset. All collections
 using it will get the changes, and all of them will be reloaded after a
 change.

 Shouldn't those APIs be at a different level/outside the collection?
 Maybe a configset API? Or, maybe the configs (for example, the
 configoverlay.json) should only apply to the collection where the API call
 was made and not to other collections using the configset?

 Tomás




 --
 -
 Noble Paul





 --
 -
 Noble Paul

Re: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 46430 - Failure!

[david.w.smi...@gmail.com]

That test utility class was ported (copied) from Spatial4j.  As a copy, it
could be modified to extend LTC.  Ideally, Spatial4j would publish the test
JAR so that this could have been used without copying it (which will be
addressed in the next release; Nick fixed this)… although then extending
LTC wouldn’t be an option then any way.

On Mon, May 11, 2015 at 8:56 AM Karl Wright daddy...@gmail.com wrote:

 If you're asking me, I don't know; David supplied the randomized test
 framework.

 Karl

 On Mon, May 11, 2015 at 8:51 AM, Michael McCandless m...@elastic.co
 wrote:

 On Mon, May 11, 2015 at 5:32 AM, Dawid Weiss 
 dawid.we...@cs.put.poznan.pl wrote:


  Hmm odd that test-framework did not print the Reproduce with: ...
 line here

 This isn't odd.  This class does not inherit from LTC; the reproduct
 with line is a listener attached to the LTC only.


 Duh, thanks Dawid, I didn't see that.

 Is there a reason why RandomizedShapeTestCase doesn't extend LTC?

 Mike McCandless

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2270 - Failure!

[david.w.smi...@gmail.com]

This turned out to be a bug in the test infrastructure that Geo3d uses,
copied from Spatial4j: Permalink
https://issues.apache.org/jira/browse/LUCENE-6196?focusedCommentId=14531165page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14531165
  I’m fixing.

On Wed, May 6, 2015 at 1:06 PM Policeman Jenkins Server jenk...@thetaphi.de
wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2270/
 Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

 1 tests failed.
 FAILED:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect

 Error Message:
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect
 Pt(x=36.3684088252,y=-89.97395823916177)

 Stack Trace:
 java.lang.AssertionError: Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)
 intersect Pt(x=36.3684088252,y=-89.97395823916177)
 at
 __randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.assertTrue(Assert.java:43)
 at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
 at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
 at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:136)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:166)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:401)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)




 Build Log:
 [...truncated 8159 lines...]
[junit4] Suite:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest
[junit4]   1 S-R Rel: {}, Shape {}, Rectangle {} [WITHIN,
 Geo3dShape{GeoRectangle: {toplat=-1.5168556919397584(-86.90942927854432),
 bottomlat=-1.5706704561465907(-89.9927881430875),
 leftlon=-0.018526106616054788(-1.0614677199093308),
 rightlon=0.06206550121582512(3.5560912730308587)}},
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)](no slf4j subst; sorry)
[junit4] FAILURE 3.57s J1 | Geo3dShapeRectRelationTest.testGeoBBoxRect
 
[junit4] Throwable #1: java.lang.AssertionError:
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect
 Pt(x=36.3684088252,y=-89.97395823916177)
[junit4]at
 __randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
[junit4]at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
[junit4]at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
[junit4]at
 

Re: Modifying DefaultSolrHighlighter

[david.w.smi...@gmail.com]

Hi Dmitry,

I am pretty well versed in the sub-class-ability of
DefaultSolrHighlighter.  Most likely the problem you see is that you are
using the no-arg constructor.  Instead, pass in a SolrCore.  It is called
via reflection.  In 5.2 I removed the no-arg constructor.

~ David

On Tue, May 5, 2015 at 4:24 AM Dmitry Kan dmitry.luc...@gmail.com wrote:

 Hi,

 We need to modify the behaviour of DefaultSolrHighlighter class slightly.
 When we tried to extend the class, Solr prints NPE.

 Is there some reason to the NPE when extending the class?

 Thanks,

 Dmitry Kan

Re: Modifying DefaultSolrHighlighter

[david.w.smi...@gmail.com]

Yes.

On Tue, May 5, 2015 at 8:29 AM Dmitry Kan dmitry.luc...@gmail.com wrote:

 Hi David,

 Thanks for replying so quick! Indeed, the NPE points to SolrCore being
 null. So of the following two ctors:

 public DefaultSolrHighlighter() {
 }

 public DefaultSolrHighlighter(SolrCore solrCore) {
   this.solrCore = solrCore;
 }



 should we use the second one?

 Regards,
 Dmitry

 On 5 May 2015 at 15:03, david.w.smi...@gmail.com david.w.smi...@gmail.com
  wrote:

 Hi Dmitry,

 I am pretty well versed in the sub-class-ability of
 DefaultSolrHighlighter.  Most likely the problem you see is that you are
 using the no-arg constructor.  Instead, pass in a SolrCore.  It is called
 via reflection.  In 5.2 I removed the no-arg constructor.

 ~ David

 On Tue, May 5, 2015 at 4:24 AM Dmitry Kan dmitry.luc...@gmail.com
 wrote:

 Hi,

 We need to modify the behaviour of DefaultSolrHighlighter class
 slightly. When we tried to extend the class, Solr prints NPE.

 Is there some reason to the NPE when extending the class?

 Thanks,

 Dmitry Kan

Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 12349 - Failure!

[david.w.smi...@gmail.com]

The root cause is that Spatial4j’s DistanceUtils.distHaversineRAD returned
NaN for a pair of anti-podal points.  I filled a bug in Spatial4j:
https://github.com/spatial4j/spatial4j/issues/104

On Thu, Apr 30, 2015 at 10:19 PM david.w.smi...@gmail.com 
david.w.smi...@gmail.com wrote:

 I’ll look into it.


 On Thu, Apr 30, 2015 at 10:17 PM Policeman Jenkins Server 
 jenk...@thetaphi.de wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12349/
 Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseG1GC

 1 tests failed.
 FAILED:
 org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations
 {#6 seed=[B2B9C743868F80F5:2826A9642D5B4E9E]}

 Error Message:
 [Intersects] Should have matched I#3:Circle(Pt(x=-94.0,y=-12.0), d=45.0°
 5000.49km) Q:Circle(Pt(x=86.0,y=12.0), d=64.5° 7172.92km)

 Stack Trace:
 java.lang.AssertionError: [Intersects] Should have matched
 I#3:Circle(Pt(x=-94.0,y=-12.0), d=45.0° 5000.49km)
 Q:Circle(Pt(x=86.0,y=12.0), d=64.5° 7172.92km)
 at
 __randomizedtesting.SeedInfo.seed([B2B9C743868F80F5:2826A9642D5B4E9E]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:121)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
 at
 org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations(CompositeStrategyTest.java:99)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:502)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
 at
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate

Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 12349 - Failure!

[david.w.smi...@gmail.com]

I’ll look into it.

On Thu, Apr 30, 2015 at 10:17 PM Policeman Jenkins Server 
jenk...@thetaphi.de wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12349/
 Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseG1GC

 1 tests failed.
 FAILED:
 org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations
 {#6 seed=[B2B9C743868F80F5:2826A9642D5B4E9E]}

 Error Message:
 [Intersects] Should have matched I#3:Circle(Pt(x=-94.0,y=-12.0), d=45.0°
 5000.49km) Q:Circle(Pt(x=86.0,y=12.0), d=64.5° 7172.92km)

 Stack Trace:
 java.lang.AssertionError: [Intersects] Should have matched
 I#3:Circle(Pt(x=-94.0,y=-12.0), d=45.0° 5000.49km)
 Q:Circle(Pt(x=86.0,y=12.0), d=64.5° 7172.92km)
 at
 __randomizedtesting.SeedInfo.seed([B2B9C743868F80F5:2826A9642D5B4E9E]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:127)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:121)
 at
 org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:56)
 at
 org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations(CompositeStrategyTest.java:99)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:502)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
 at
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
 at
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at