Re: Using rows=-1 for "give me all"

: > : Back when we used 4.4.0 I believe a query with rows=-1 returned all : > matching : > Nope -- that's never been how rows=-1 behaved. : Believe you are wrong. That was how it behaved in 4.4.0 Nope -- not in a regular search it didn't...

Re: Using rows=-1 for "give me all"

: Back when we used 4.4.0 I believe a query with rows=-1 returned all matching : documents. In 5.1.0 (the one we are using now) rows=-1 will trigger a Nope -- that's never been how rows=-1 behaved. The fact that it didn't return an error is some older versions of solr (and may have behaved

RE: lucene-solr:master: Move non-inner classes to separate files: This breaks IDEs and update checks by javac

: I found out that there are more of those in the facets module. Can we : change those to be real *inner* classes or put them in separate files? +1 ... it's a really obnoxiou missfeature of java in my opinion ... are there any static tools we can enable to fail the build for classes like

Re: lucene-solr:master: remove unnecessary Placeholder and mark old codec deprecated

I don't have git repo handy to verify, but I think this may have broken precommit and be causing some recent jenkins failures? http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/576/consoleText : [copy] Copying 1 file to

Re: Lucene/Solr JIRA Fix Version question

: I wasn't suggesting a blanket resolve of issues. There are a few that I : looked at that should have been resolved and weren't. This would require : some manual effort. can you give some examples? I was reading "resolved" as "FIXED" but if you're talking about issues that could/should be

Re: Lucene/Solr JIRA Fix Version question

TLDR: I don't think it's worth any time/effort to worry about fixVersion for open issues. : project in (SOLR,LUCENE) and status in (Open) and fixVersion IS NOT EMPTY : : Does it make sense that there are so many issues that are open and have a : fixVersion that is not empty? Yes, there are

[jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'

[ https://issues.apache.org/jira/browse/LUCENE-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275399#comment-15275399 ] Chris Hostetter commented on LUCENE-7271: - Closing all issues with a certain fix version affects

Re: lucene-solr:master: SOLR-8972: Add GraphHandler and GraphMLResponseWriter to support graph visualizations

Joel: adding /graph to the list of ImplicitPlugins has broken MinimalSchemaTest.testAllConfiguredHandlers (see recent jenkins failures) : Date: Thu, 5 May 2016 20:29:33 + (UTC) : From: jbern...@apache.org : Reply-To: dev@lucene.apache.org : To: comm...@lucene.apache.org : Subject:

jira git bot skipping janhoy -- was: Re: [jira] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

: [~markrmil...@gmail.com], I don't think that a single one of my GIT : commits have ever been tagged by the tag bot... It does not like me :( that's really bizzare -- you should definitely file a jira with infra to try and get to the bottom of this. -Hoss http://www.lucidworks.com/

Re: lucene-solr:master: added a couple of extra methods

This is a convention followed Scala. Tuple2 ( : >>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 ( : >>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html) : >>> : >>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter < : >>> hossm

Re: lucene-solr:master: added a couple of extra methods

ly a key and value. In that case, it makes sense : >> to use the index . : >> : >> : >> This is a convention followed Scala. Tuple2 ( : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 ( : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)

Re: [JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 110 - Still Failing!

Interesting SSL failures coming solely from Solaris since adding NullSecureRandom to our SSL tests, tracking here... https://issues.apache.org/jira/browse/SOLR-9068 : Date: Wed, 4 May 2016 08:20:59 + (UTC) : From: Policeman Jenkins Server : To: sar...@gmail.com,

Re: post-branch_6x Jira version renaming(s) got overlooked?

-7271 : Date: Fri, 29 Apr 2016 15:41:06 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: Lucene Dev <dev@lucene.apache.org> : Subject: Re: post-branch_6x Jira version renaming(s) got overlooked? : : : : OK. I'm not sure you're missing anything. But, I think we

Re: [JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 565 - Still Failing!

Gah ... not sure how i missd that. ... fix coming. : Date: Wed, 4 May 2016 01:02:44 + (UTC) : From: Policeman Jenkins Server : To: sar...@gmail.com, daddy...@gmail.com, hoss...@apache.org, : dev@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-6.x-Linux

Re: lucene-solr:master: added a couple of extra methods

WTF is this? why are these (poorly named) alternatives for getKey and getValue useful? : Date: Tue, 3 May 2016 15:09:08 + (UTC) : From: no...@apache.org : Reply-To: dev@lucene.apache.org : To: comm...@lucene.apache.org : Subject: lucene-solr:master: added a couple of extra methods : :

Re: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+115) - Build # 544 - Failure!

I can't repro this, but I'm pretty sure i understand what's going on here -- and i think the problem is that this test (which is only on 6x) is just straight up broken, but the brokenness wasn't obvious until i made the recent changes in SOLR-9028. I'll track fixing this in SOLR-9028. :

Re: post-branch_6x Jira version renaming(s) got overlooked?

audits we need/want to do can be done after the fact using searches on those magic strings. when it's time for auditing those ~100 6.1 jiras it might be worth splitting up the work, but it should go pretty quick. : : On Fri, Apr 29, 2016 at 2:47 PM, Chris Hostetter : <hossman_luc...@fucit.org&g

Re: post-branch_6x Jira version renaming(s) got overlooked?

: Yeah, good point, I forgot about the permutations with backported issues. : : But it's not just master + 6.1, it's also master + 6.0. That's why : the query I sent out looked for issues that had "master", but not : either of those versions. If it's marked for 6.0 and also master, then : it's

Re: post-branch_6x Jira version renaming(s) got overlooked?

;merge versions" and manually auditing the ~100 issues that already have master+6.1 ... which is probably as tedious as i'm willing to volunteer to be at this point (if other people wnat to volutneer for something more tedious i'm happy to let them) : On Fri, Apr 29, 2016 at 2:11 PM C

Re: post-branch_6x Jira version renaming(s) got overlooked?

: Is it possible there are 2100 of these? Possible or not, that's certialy what it looks like (1665 more in LUCENE) I woke up this morning thinking "Oh wait - doesn't jira have a way to merge Versions?" ... and the answer is "Yes" so i was going to suggest the following... for both the

Re: [JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_92) - Build # 5806 - Still Failing!

I'm looking into these SSL exceptions ... looks like diff JVMs/OSs cause diff exceptions in these (expected) certificate failure situations ... i'll relax the expectThrows calls to account for this. (see SOLR-9028) : Date: Thu, 28 Apr 2016 23:21:51 + (UTC) : From: Policeman Jenkins Server

Re: post-branch_6x Jira version renaming(s) got overlooked?

kept getting : created again. I figured the rollover was not done right, but with no other : complaints I did not really look. Some people with JiRa admin power had : different ideas. : On Wed, Apr 13, 2016 at 6:40 PM Chris Hostetter <hossman_luc...@fucit.org> : wrote: : : > : > I just noticed

Re: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3224 - Still Failing!

https://issues.apache.org/jira/browse/SOLR-8992 : Date: Thu, 21 Apr 2016 19:37:16 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org : To: no...@apache.org, nkn...@apache.org, markrmil...@apache.org, : jpou...@gmail.com,

Re: Solr Ref Guide for 6.0

The ref guide is virtually ready to publish, but one major blocker is that we still need someone with CWIKI admin privleges to update the javadoc macros... : Uwe, would you do that thing to update the Javadoc link paths? As described : here: :

useCompoundFile in ref guide -- was: Re: [jira] [Commented] (SOLR-4941) useCompoundFile default has changed, simple config option no longer seems to work

Incidently Smiley: there is absolutely still time to improve the wording of the 6.0 ref guide explanation of what useCompoundFile is and what it does -- edit away. : is only about flushed segments from newly indexed : documents, yet its setting name doesn't reflect it's limited to just :

Re: Solr Ref Guide for 6.0

: I don't think this should prevent a hypothetical 5.6 release of the code : (Lucene/Solr itself). It would just either not have a companion ref guide, : or maybe we could add some simple addendum (some simple pages) to the front : or something. I don't have a link handy, but I remember this

post-branch_6x Jira version renaming(s) got overlooked?

I just noticed that most of the (older) jira's listed in 6.0's CHANGES.txt files are still showing up in Jira as being fixed in "master" Examples... https://issues.apache.org/jira/browse/LUCENE-5950 https://issues.apache.org/jira/browse/LUCENE-6631

Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 514 - Failure!

http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/88965a0b : Date: Mon, 11 Apr 2016 14:11:31 -0400 : From: Michael McCandless : Reply-To: dev@lucene.apache.org : To: Policeman Jenkins Server : Cc: m...@apache.org, tomm...@apache.org, :

Re: Solrj API for Managed Resources

https://people.apache.org/~hossman/#solr-user Please Use "solr-user@lucene" Not "dev@lucene" Your question is better suited for the solr-user@lucene mailing list ... not the dev@lucene list. The dev list is for discussing development of the internals of Solr and the Lucene Java library ... it

Re: [CONF] Apache Solr Reference Guide > Upgrading a Solr Cluster

: > ...but maybe we should move it up into the "Run the Solr Installation : > Script" subsection and generalize it? : > : > "NOTE: the remainder of this doc assumes you use the install script : > defaults, some directories and filenames may change if you override : > options, such as the "-s

Re: [CONF] Apache Solr Reference Guide > Upgrading a Solr Cluster

: > The goal here should be to keep the upgrade steps simple, focus on the : > common case, and have minimal distractions for the uncommon cases. : : I moved it, then took it out after thinking about it a little more. I : see that the "taking solr to production" page already has this specific

Re: [CONF] Apache Solr Reference Guide > Upgrading a Solr Cluster

:   : Change comment: fix very minor error -- /ec/default instead of /etc/defaults. Also indicate that the solr.in.sh : file will get a different name if the service name is changed. In a few places the text said "Solr 5". Removed the Shawn: thanks for those edits -- but i do not think it's a

Re: Proposed extension to SearchHandler / SearchComponent in Solr

: Recently I was writing a SearchComponent which works only in a distributed : context. In the prepare method it alters some static state, and then : reverts that modification during one of the calls to finishStage. However, : I realized that if an exception is thrown by another SearchComponent,

Re: SolrCloud App Unit Testing

Naveen: As a "user" of Solr, wanting to develop tests for your solr based application you'll probably get more responses on the solr-user@lucene list (the dev@lucene is for discussing hte development of lucene & solr themselves) The quick answer is that, assuming you are writting your tests

Re: lucene-solr:master: disable query cache when this test uses threads, so seeds reliably reproduce

Mike, can you clarify why the query cache is problemtic here ... it's not really clear from the comment you added... : +if (useThreads) { : + // We must disable query cache otherwise test seed may not reproduce since different : + // threads may or may not get a cache hit or miss

Re: [JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 32 - Still Failing!

I opened an issue for this with my analysis of the test log, but i honestly can't make heads of tails of it... https://issues.apache.org/jira/browse/SOLR-8914 : Date: Sat, 26 Mar 2016 10:25:50 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org

Re: Solr date formatting/parsing; upgrade to java.time

: I started a quick hack to cut over DateFormatUtil's formatting to this : one-liner: DateTimeFormatter.ISO_INSTANT.format(d.toInstant());and ... : I'd love to just cut over to this but there are some slight differences we : would see and I want to get people's opinion if any of

Re: Git Policy/Preference: how to fold in feature branches? squash?

: I also think having large changes broken up is useful, even when not : viewing with first parent. But it's a judgement call. If I have a tiny : commit, and I tweak it maybe from a review comment, then I will usually : squash. If I have a large commit I am working on, I try to make each commit :

Re: Git Policy/Preference: how to fold in feature branches? squash?

: > It may only create a single commit, but from the perspective of people : > viewing master, it "adds" every commit that was on the jira/SOLR-445 : > branch to the master branch -- generating an metric ass-ton of : > emails among other things, but more importantly it pollutes history : > with a

Re: Git Policy/Preference: how to fold in feature branches? squash?

: 1) git merge (no fast forward) : : This creates a single merge commit that points to two parents -- the It may only create a single commit, but from the perspective of people viewing master, it "adds" every commit that was on the jira/SOLR-445 branch to the master branch -- generating an

Git Policy/Preference: how to fold in feature branches? squash?

SOLR-445 is fairly well done, and i'm ready to land it on master (and eventually branch_6x) My impression is that the sanest way to do that is... # on master ... git merge --squash jira/SOLR-445 emacs CHANGES.txt # to add CHANGES entry git commit -m "Merging branch

Re: [JENKINS] Lucene-Solr-Tests-6.x - Build # 65 - Failure

Weirdness... https://issues.apache.org/jira/browse/SOLR-8864 : Date: Wed, 16 Mar 2016 21:39:31 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-Tests-6.x - Build # 65 - Failure :

Re: git email format customizability: add branch to subject?

: Any other concerns/opinions before i mover forward with contacting infra? For those of you that haven't been following INFRA-11462, or paying attention to commits@lucene, this change has been made. : One other thing i recently realized is that tag creation notification : emails don't seem

Re: Branch update merge blizzards

: Is there some specific intent why there should be commit-level email for a : mere non-release branch update? I mean, does anybody get any value from : them? I do want to see them if master or branch_xy gets merged into, but : not for branches LUCENE/SOLR-, especially when each of those Jira

Re: git email format customizability: add branch to subject?

I got side tracked, but I've filed a jira with this request... https://issues.apache.org/jira/browse/INFRA-11462 : Date: Mon, 22 Feb 2016 14:09:51 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: dev@lucene.apache.org, Christine Poerschke <cpoersc...@bloo

Re: lucene-solr git commit: SOLR-8765: Set parameters correctly in async shard requests

: Hm, this is weird - git appears to be using my apache email address : (configured for this particularly repository) as author emails, but then : using global settings for the committer address. But, if I run git log : --pretty=full locally, then it shows my apache email address for both :

Re: lucene-solr git commit: SOLR-8697: Add synchronization around registering as leader and canceling.

this breaks precommit... [forbidden-apis] Forbidden method invocation: java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default locale] [forbidden-apis] in org.apache.solr.cloud.OverseerTest$MockZKController (OverseerTest.java:128) [forbidden-apis] Scanned 3181 (and 1946

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

Hmmm... for me, i haven't been able to reproduce these seeds since trying "ant clean-jars" ... aren't the jenkins builds already doing that? : Date: Fri, 26 Feb 2016 14:42:20 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: Lucene Dev <dev@lucene.ap

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

: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16008/ : Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC I'm seeing some (very) reproducible failures similar to these -- the root causes cases coming from NPEs from IOUtils.copyLarge ...

Re: [ANNOUNCE] Apache Solr 5.5.0 released

Mike: you CC'ed the Solr release announcement to java-user, instead of solr-user and you used an old copy of the ReleaseNote55 wiki page that didn't include the ref guide release comments I added yesterday. https://wiki.apache.org/solr/ReleaseNote55 I'll go ahead and resend the complete

Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

, 22 Feb 2016 13:46:55 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: Lucene Dev <dev@lucene.apache.org> : Cc: gene...@lucene.apache.org : Subject: Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf : : : VOTE has passed, i'll begin pushing to mirrors. : : : : D

Re: git email format customizability: add branch to subject?

: +1 for keeping the repo name but perhaps we could drop the "git: " prefix? : : Without the prefix the subject would still be fairly distinguishable : from the "svn commit" emails such as "svn commit: r1731559 - : /lucene/cms/trunk/content/extpaths.txt" (assuming the svn commit emails : keep

Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

VOTE has passed, i'll begin pushing to mirrors. : Date: Fri, 19 Feb 2016 16:05:18 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: Lucene Dev <dev@lucene.apache.org> : Cc: gene...@lucene.apache.org : Subject: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf :

Re: git email format customizability: add branch to subject?

: https://git-wip-us.apache.org/docs/switching-to-git.html seems to : suggest there is per project flexibility. Branch not one of the : (currently) available variables though, no? : : +1 for "the branch be included in the subject" Thanks for finding that link Christine, I pinged #infra on

VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

Please VOTE to release the following artifacts as apache-solr-ref-guide-5.5.pdf ... https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.5-RC1/ -Hoss http://www.lucidworks.com/ - To

Re: VOTE: RC0 Release apache-solr-ref-guide-5.5.pdf

Christine & Bernhard Frauendienst spotted a couple of very confusing formatting glitches, so i'm going to respin an RC1 in a few minutes. : Date: Fri, 19 Feb 2016 11:07:46 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: Lucene Dev <dev@lucene.apache.or

Re: VOTE: RC0 Release apache-solr-ref-guide-5.5.pdf

Heh ... replying back with general@lucene CC'ed correctly this time. : Date: Fri, 19 Feb 2016 11:06:36 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: Lucene Dev <dev@lucene.apache.org> : Cc: gene...@lucene.apache.og : Subject: VOTE: RC0 Release apache-solr-r

VOTE: RC0 Release apache-solr-ref-guide-5.5.pdf

Please vote to release the following artifacts as apache-solr-ref-guide-5.5.pdf https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.5-RC0 -Hoss http://www.lucidworks.com/ - To unsubscribe,

Re: Solr Ref Guide for 5.5

It looks like we're in pretty good shape -- only a few more crucial changes in 5.5 need documented and it looks like folks are actively working on those. I talked to cassandra a bit offline -- She's about to leave on vacation for a few days, so i'll take responsibility for cutting the first

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

: >Everything else... well, I don't understand why it does so much, let's : >leave it at that :) : : I think it does that to get the changes since last build. No idea what : rev-parseand rev-list do, this is the git hell and there is no escape. it's general jenkins plumbing that can serve

git email format customizability: add branch to subject?

Does anyone know how much per project flexibility we have on the format of the "git commit" emails sent to commits@lucene ? In particular: is it possible to ask INFRA that the branch be included in the subject, w/o that being a massive change that affects every apache project? ie: switch

Re: git commits on JIRA issues;

: 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;

Re: git commits on JIRA issues;

: > 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 : >

Re: git commits on JIRA issues;

: 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. I will take your word for it. (I ignored most of the early "if/when/should/why" threads about switching to git

Re: Question about release plans amidst the git transition

: My only comment is that 5.5 coming just a few days after 5.4.x seems : pretty short, but maybe it'll take a month to get the first Git build : ironed out anyway... Even if if everything goes smoothly and we discover that magically everything still works and we are "ready" to do a 5.5 release

Re: GIT migration date (SVN freeze)

: You will have access to the source code -- the SVN remains functional, : but it'll be an empty folder on the branches I mentioned. 1 suggestion Dawid... Just before you run the massive "svn rm" command(s) needed for the wiping commit(s), please run "svnversion" on each branch and make a note

Re: GIT migration date (SVN freeze)

: I will do what you ask for, Hoss, although the cloned git repo records : every single SVN revision in the commit log anyway, so it should be : relatively easy to find which commit (SVN and otherwise) preceded the : move. Sure -- my suggestion was not based on any worries about the "post svn"

Re: Moving Lucene / Solr from SVN to Git

: INFRA-11056: Migrate Lucene project from SVN to Git. : https://issues.apache.org/jira/browse/INFRA-11056 Mark: Infra uses non standard Jira workflows, and the last infra action was to toggle the state to "Waiting for user" -- Dawid & Uwe posted followup questions for Infra in that issue, but

Re: svn commit: r1720613 - in /lucene/dev/trunk/solr: ./ core/src/java/org/apache/solr/client/solrj/embedded/ core/src/java/org/apache/solr/cloud/ core/src/java/org/apache/solr/core/ core/src/java/org

I'm a little concerned that this implemenation of TestInjection will cause wasted cycles (sometimes in tight loops) for non-test situations when users have asserts are enabled. Can we at least leverage some final static variable(s) to try and help HotSpot optimize these method calls away when

Re: svn commit: r1720085 - /lucene/cms/trunk/content/core/quickstart.mdtext

I thought there was a macro to refer to the latest stable version# so edits like this didn't need to be made after every release? And isn't there a redirect path for the same purpose? Something like this i think (looking at other existing pages)... Lucene {% include

RE: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build # 5439 - Failure!

: Date: Wed, 2 Dec 2015 16:20:52 -0600 : From: "Dyer, James" : Reply-To: dev@lucene.apache.org : To: "dev@lucene.apache.org" : Subject: RE: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build # : 5439 - Failure! : : I'm

documentation-lint failures on 5x branch?

I'm seeing the failures from documentation-lint on the 5x branch when running ant precommit (both using java7 and java8) ... see below. 1) is it my imagination of are the smokerelease jobs on jenkins not running documentation-lint? i don't see it in the logs...

Re: documentation-lint failures on 5x branch?

nd API bugs like this with the link checker? (or an alternative static analysis tool we can use to find these bad API visibility bugs) (i'll open a jira to clean these up these specific ones now that we know about them) : : Le lun. 23 nov. 2015 à 19:36, Chris Hostetter <hossman_luc...@f

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_66) - Build # 14940 - Still Failing!

I'm digging into these... : Date: Tue, 17 Nov 2015 13:58:58 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org : To: sh...@apache.org, cpoersc...@apache.org, dev@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_66)

Re: test suite counter skipping numbers?

: > Tests summary: 100 suites (2 ignored), xx tests, xx ignored (xx assumptions). : : Will do it in the next version. Thanks for letting me know. Dawid: that reminds me, if you are tweaking the logging, it would also be helpful if the "Completed [X/Y] ..." line after each test also indicated

Re: Sharing a class across cores

: However, my take on it is that this seems like a pretty broad brush to : paint with to move *all* our classes up and out of the normal core loading : process. I assume there are good reasons for segregating this stuff into : separate class loaders to begin with. It would also be fairly

Re: [JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3722 - Failure

These recent jenkins OverseerTest faiulres (seems to have started failing yesterday for the first time) all have seeds that reproduce 100% reliably for me... 5x... ant test -Dtestcase=OverseerTest -Dtests.method=testOverseerStatsReset -Dtests.seed=7B352AEEA690CBAB -Dtests.multiplier=2

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

Mike: please forward me the entire email (from jenkins) that you recieved with all headers. I don't believe this email ever made it to the dev@lucene moderation queue at all (i can't find a record of it at first glace, but because of how the moderation queue uses attachments it's a pain to

Re: Any clue why I'm being asked to moderate these messages from the build system?

: bu...@elastic.co *is* on the allow list for dev, so dunno why it is in : the moderation queue. As discussed before on the dev-owner list (for the specific purpose of not distracting the entire dev community with mailing list management issues -- but alas, since it keeps coming up here i'll

Re: Any clue why I'm being asked to moderate these messages from the build system?

: Every individual email "From: bu...@elastic.co" is usually a completley : distinct "Return-Path" header... ... : ...these addresses are what get compared against hte subscription lists : (and auot-alowed whitelists). Acctually ... just to clarify: ezmlm verifies

Re: Can no longer override IndexConfig values in solrconfig.xml?

: I was not up to date on this: : : http://www.w3.org/2001/XInclude"/> : : First XML include I've ever seen in practice. dude... that's been in all solr (core) tests since summer 2013. where you been? -Hoss http://www.lucidworks.com/

Re: Can no longer override IndexConfig values in solrconfig.xml?

: On trunk, when I add the following to the solrconfig.xml, I can't load a : SolrCore. What am I doing wrong? ... : There is only the indexConfig I have added. are you sure? file a bug and attach your entire solr home dir, because i can't reproduce with the following configs -- the

Re: Permission to create cwiki page?

you should be good to go. -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: Permission to create cwiki page?

: Not that I have anything immediate to update, but could I be added also? : My username should be just "upayavira". Also done. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For

RE: svn commit: r1697131 - in /lucene/dev/trunk/lucene: JRE_VERSION_MIGRATION.txt test-framework/src/java/org/apache/lucene/util/TestUtil.java

: I will change that as suggested. The assert in the StringBuilder loop : can be removed completely, if we checked that before. No worries -- I'll take care of it -- i'm the one that wants the test, i don't mind doing the work. I just didn't want to mess with it before until i understood the

Re: svn commit: r1697131 - in /lucene/dev/trunk/lucene: JRE_VERSION_MIGRATION.txt test-framework/src/java/org/apache/lucene/util/TestUtil.java

Uwe: I'm still concerned about this change and the way it might result in confusing failure messages in the future (if the whitespace def of other characters changes) ... can you please explain your choice Assert.assertTrue - assert ? On Mon, 24 Aug 2015, Chris Hostetter wrote: : Uwe: why

RE: svn commit: r1697131 - in /lucene/dev/trunk/lucene: JRE_VERSION_MIGRATION.txt test-framework/src/java/org/apache/lucene/util/TestUtil.java

: 1) The test framework never randomly disables asserts (it cannot do : this, because asserts are enabled before the VM starts - you cannot do Hmm, ok -- i thought this was happening when the JVM was forked. In any case, my underlying concern still seems valid to me: confusing nonsensical

Re: svn commit: r1697131 - in /lucene/dev/trunk/lucene: JRE_VERSION_MIGRATION.txt test-framework/src/java/org/apache/lucene/util/TestUtil.java

Uwe: why did you change this from Assert.assertTrue to assert ? In the old code the test would fail every time with a clear explanation of hte problem -- in your new code, if assertions are randomly disabled by the test framework, then the sanity check won't run and instead we'll get a

Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b25) - Build # 13936 - Failure!

Hmm... I'm suprised i didnt' hit this in my beasting -- but it makes sense, both qualifications and jobs have a year field (which is what i'm doing a parent query on) I'm working on the fix. : Date: Thu, 20 Aug 2015 21:06:39 + (UTC) : From: Policeman Jenkins Server jenk...@thetaphi.de

Re: VOTE: RC1 release of apache-solr-ref-guide-5.3.pdf

+1 to releasing this... : 1255cba4413023e30aff345d30bce33846189975 apache-solr-ref-guide-5.3.pdf -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail:

Re: Suggestion for overriding equals() method

Fuxiang: thank you for your email about this. I've filed this in our jira tracker -- if you have a patch you'd like to provide to help move this issue forward, please attach there... https://issues.apache.org/jira/browse/LUCENE-6744 https://wiki.apache.org/lucene-java/HowToContribute :

Re: 5.3 release

: I'm confused: this issue isn't a blocker? Why are we holding up a : release for non-blocker issues? If i understand correctly, SOLR-7838 is (part of) a feature and by definition not a blocker -- but after being committed Shalin noticed that the syntax of the user facing API introduced in

Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5103 - Failure!

I caused this in https://issues.apache.org/jira/browse/LUCENE-6609 digging in -- i could just supress the problematic codecs, but i'd like to refactor so only the problematic bits will be skipped in those cases and leave the bulk of the test running all the time. : Date: Tue, 4 Aug 2015

Re: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ dev-tools/ lucene/ lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ lucene/analysis/common/src/java/org/apache

Mikhail: something doesn't make sense about the CHANGES.txt entry for this after the merge (I noticed doing a subsequent merge) On the 5x branch SOLR-6234 is in the New Features section of 5.3, but on trunk it's in Other Changes of 6.0. : Date: Tue, 28 Jul 2015 14:44:17 - : From:

RE: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b73) - Build # 13391 - Failure!

: Unfortunately this is not so easy. It is always the same Jenkins Job, : the randomization is part of the dynamic JAVA_HOME. So the mail is Ah ... ok. What about adding a second (no mail configured) job for untrusted JDK9 (and if we start getting them: new IBM J9) builds? ie: your existing

RE: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b73) - Build # 13391 - Failure!

: It was just a try with newer build. And no, the machine has no hardware : failure, happens all the time with JDK 9 L - and only with Java 9 b67+ Uwe: perhaps you could change your JDK9 jenkins job to run but not send emails on failures? then at least we can still generate reports, and test

Re: timeAllowed parameter ignored edge-case bug?

: In the scenario outlined below, the second run's timeAllowed parameter : is unexpectedly ignored. Could this be intentionally so somehow (q vs. : fq processing?, Collector vs. LeafCollector?, DocList vs. DocSet?), or : is it an edge-case bug? Based on your description (didn't re-review the

RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

: : - : Uwe Schindler : H.-H.-Meier-Allee 63, D-28213 Bremen : http://www.thetaphi.de : eMail: u...@thetaphi.de : : : -Original Message- : From: Chris Hostetter [mailto:hossman_luc...@fucit.org] : Sent: Wednesday, July 08, 2015 11:46 PM : To: dev@lucene.apache.org : Subject: RE

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

2 nearly identical failures from policeman immediatley after upgrading jdk1.9.0 to b71 ... seems like more then a coincidence. ant test -Dtestcase=ExtractingRequestHandlerTest -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED -Dtests.multiplier=3 -Dtests.slow=true

RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

://www.thetaphi.de : eMail: u...@thetaphi.de : : :-Original Message- :From: Chris Hostetter [mailto:hossman_luc...@fucit.org] :Sent: Wednesday, July 08, 2015 7:42 PM :To: dev@lucene.apache.org :Cc: sh...@apache.org :Subject: Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit

<    1   2   3   4   5   6   7   8   9   10   >