FYI: The gitbox web UI is deliberately returning 403 most URLs (besides
the basic "commit summary") as a spam/abuse prevention mechanism
The official recommendation from infra is "Browse / review commits on
github"
-Hoss
-- Forwarded message --
Date: Mon, 11 Mar 2019 01:10
Seems like a test (or code) bug introduced when this test was
added by LUCENE-8585 ...
https://issues.apache.org/jira/browse/LUCENE-8585
: Date: Tue, 26 Feb 2019 08:59:25 + (UTC)
: From: Apache Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENK
: Do we need to disable the JDK 13 builds for 8.0, or change the assumptions
here? Does Mockito work with JDK 13?
The message about Mockito is a red-herring -- that comes from an failed
*assumption* which is already checking if the current version of mockito
works or not on the current JVM in
: OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
: from master, and am in the process of updating the master branch to
: version 9. New commits that should be included in the 8.0 release
: should also be back-ported to branch_8x from master.
It looks like someone rena
+1
: Date: Mon, 10 Dec 2018 09:36:46 -0600
: From: Cassandra Targett
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: VOTE: Solr Reference Guide for Solr 7.6 RC1
:
: Please vote for the release of the Solr Reference Guide for 7.6:
:
: The PDF artifacts can be downloade
I don't know what might be the cause/corrolation of this, and i haven't
tried to investigate the logs in depth, but i thought i should point it out...
In the past week, the failure rate of these 2 nightly tests has increased
~20-25% as compared to the prior 3 (calendar) weeks...
Class: org
There was a logging change that miller made on master ~Nov29 (and
backported to 7x a few days later) that i just dialed down from INFO to
DEBUG ... was causing an INFO log message once a second from every solr
core, which can add up in long running tests.
might explain the recent up tick...
d
: Seeing TimeRoutedAliasUpdateProcessorTest on the 7.6 bad apple list, having
: recently been looking at that test, and waiting on a long build for other
: work, I went to http://fucit.org/solr-jenkins-reports/failure-report.html
: to gather recent failures, and when I started looking I began to
: first place. Some things were wrapped in "multiple-failure" exception,
: which didn't seem right to me. When I wrote the dedicated runner there
: was a lot of guessing involved, including XML reports (this bit not
: even part of JUnit, but Apache Ant and Apache Maven).
...
: It's actua
: bq. if the jenkins build re-runs a TestCase 5 times, there's still
: only one section for that suite
:
: I don't know about Jenkins XML, but this behavior is quite all right.
: Suite exceptions are either from static class init blocks or from
: "outside of test" scopes (like rule initializatio
FYI: I've made some improvements to my Jenkins Test reports recently...
http://fucit.org/solr-jenkins-reports/
Most significantly: I've added a new summary report called "Suspicious
Test Failure Rate"...
http://fucit.org/solr-jenkins-reports/suspicious-failure-report.html
This summari
: Ah sorry, I did not see the ping. Where did you try to contact me?
: > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
https://issues.apache.org/jira/browse/SOLR-12990?focusedCommentId=16688433&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1
: The job would use the usual randomization anyways, so what's your
: special request? So we should see an improvement asap.
No special request beyond asking you to setup a job on your personal
jenkins server -- just pointing out that i tried asking you for this via
jira ping 2 weeks ago :)
A
: I’d prefer to just add jenkins jobs for the “http2” branch and not yet
Uwe: note that in particular it would be really helpful to have a
jira/http2 jenkins job setup on your policeman's jenkins box, where java11
and java12 are randomized, since you seem to hit the java>9 SSL related
bugs th
-reviewing everything (that and the
patch review from smiley gave me some re-assurance.)
(As far as SOLR-12962 is concerned) Feel free to cut branch_7_6 whenever
you're ready.
: On Thu, Nov 8, 2018 at 3:59 PM Chris Hostetter
: wrote:
:
: >
: > : Let me know if there are any other
: Let me know if there are any other blockers that need to be resolved prior
: to cutting the branch. If not, I will plan to cut the branch on Friday or
: (provided they are close to resolution) whenever these issues are resolved.
nknize: I'd like to try and get SOLR-12962 into 7.6...
It's a n
[smoker] Releases that don't seem to be tested:
[smoker] 6.6.5
On Fri, 6 Jul 2018, Apache Jenkins Server wrote:
: Date: Fri, 6 Jul 2018 19:17:14 + (UTC)
: From: Apache Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-Sm
these tests should really be using...
SolrException e = expectThrows(() -> {...});
...and ideally we should be making assertions about the exception message
as well (ie: does it say what we expect it to say? does it give the user
the context of the failure -- ie: containing the "non_numeric
Erick: thank you for fixing my precommit mistake when you made these
changes, sorry about that.
: Date: Thu, 21 Jun 2018 23:03:01 + (UTC)
: From: er...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr:master: SOLR-12028: BadApple and Await
Sorry guys ... i don't know how i managed to forget runniing precommit!
: Date: Thu, 21 Jun 2018 23:27:15 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: sha...@apache.org, dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Releases that don't seem to be tested:
[smoker] 6.6.4
On Tue, 22 May 2018, Apache Jenkins Server wr
: I am facing an issue on solr search version 7.x. I want to create a
: currencyFIeldType in my managed-schema file. In order to do that I created
: the following entries :
:
: * *
that configuration instructs this instance of CurrencyFieldType to use a
local file named "currency.xml" in orde
: Thanks; I can definitely appreciate that Watchers (or more generally the
: idea of chaining async callbacks) is usually a more suitable mechanism than
: calling sync(). I've also seen some code patterns in which knowledge of
To be clear: i'm not suggesting that we *don't* need sync() calls
an
IIUC, the reason you don't see any calls to sync() is because Solr's use
of ZK is mostly based on Watchers? ... so we have callback functions to be
notified anytime something (like leaeders, overseer, cluster state,
etc...) changes and those calbacks update local copies of that state,
which ot
f
people feel there is justification in saying "it wasn't really broken
before, but it's better now").
As things stand now, from the perspective of a user, i'm left thinking
"Whoa ... if autoscaling triggers weren't validated before this release,
and that did
The "Other Changes" list in the 7.4 section of solr/CHANGES.txt is
currently the largest list (by number if jiras) for all of 7.4 -- and
includes many things that AFAICT really seem like they should
be listed in one of the more specific list: New Features, Bug Fixes,
Optimizations.
I would
Possibly/Probably to reproduce/repeat/expand/disprove on previous work
done by someone else.
: Date: Thu, 5 Apr 2018 09:18:35 -0700
: From: Walter Underwood
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: Re: solr
:
: But…why do you want an obsolete version of Solr?
:
: I have not been able to get the actual SHA implementation (SHA-1,
: SHA-256...) from the MessageDigest instance. If we could get that, I
: suspect it would be different on my machine then yours.
How about this...
import java.security.MessageDigest;
public final class Temp {
public static voi
:
http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/security/provider/JavaKeyStore.java/?v=source
:
: The getPreKeyedHash method is where MessageDigest.getInstance("SHA") is
: called. From everything I've read this code is incorrect because SHA is not
: a valid
t; Joel Bernstein
: > http://joelsolr.blogspot.com/
: >
: > On Wed, Apr 4, 2018 at 12:19 PM, Chris Hostetter > wrote:
: >
: >>
: >> : Subject: Re: TestSSLRandomization is failing everytime
: >>
: >> : When I run locally I get this stack trace:
: >>
: >>
: Subject: Re: TestSSLRandomization is failing everytime
: When I run locally I get this stack trace:
would be helpful to konw the branch, and the GIT SHA ... and if you can
reproduce if you checkout an older branch/SHA where you know you didn't
see this failure in the past (ex: the last SHA y
This seems to be realted to LUCENE-7935?
I've re-opened & commented there about this failed smoketester.
: Date: Wed, 4 Apr 2018 10:14:36 + (UTC)
: From: Apache Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-SmokeRelease-master
IIUC: This looks like a maven/yetus dependency problem?
[mvn] [INFO] Error for project: Apache Solr Core (during install)
[mvn] [INFO]
[mvn] [INFO] Compilation failure
[mvn] cannot access org.apach
: The most interesting bit is probably here...
:
: http://fucit.org/solr-jenkins-reports/failure-report.html
FYI:
I realized this morning that the "Suite Runs" counts were being
artificially inflated for suites that are frequently SKIPPED (either
because they are @Nighly or @Slow and not run
ilures from lucene
package tests -- like for example: in the past 24 hours,
oal.search.TestSearcherManager has had suite level failures in 10% of the
jenkins builds in which it run...
http://fucit.org/solr-jenkins-reports/failure-report.html
: > -Original Message-
: > Fro
: * Hoss has worked on aggregating all test failures from the 3 Jenkins
: systems (ASF, Policeman, and Steve's), downloading the test results & logs,
: and running some reports/stats on failures. He should be ready to share
: this more publicly soon.
I think Steve's linked to some of this before
: Let's take solr/licenses/derby-LICENSE-ASL.txt for example which has this
: section towards the end
...
: Should we be filling out the [] and [name of copyright owner] section
: in our LICENSE files?
IIUC you're missreading that section. Note it explicitly says...
: the bra
: > It seems that emails for JIRA issues created or updated between
: >
: > 2018/01/17 19:30 and 2018/01/18 20:05 (i.e. over 24 hours)
: >
: > were created with Precedence: bulk
: >
: > Such mails are dropped by ezmlm, so the mails never got sent to any
: > mailing lists.
5 issues created on t
Jira's down for maintence, so i can't report this in jira, but...
These TestClusterStateProvider.testAutoScalingConfig failures seem to reproduce
fairly reliably for me -- across both master and branch_7x. Attempting to
generate new seeds I've never seen this test pass.
Picking one seed at ra
: (I had left the comment in question)
: I think a test shouldn't have to explicitly clean up after itself, except
: perhaps intra-method as-needed; test-infrastructure should do the class
: (test suite).
All test code should always be expected to clean up their messes at
whatever "ending" stage
Adrien: shouldn't we have a note about this in the "Changes in Runtime
Behavior" section of lucene/CHANGES.txt and the "Upgrade Notes" section of
solr/CHANGES.txt for 8.0?
: Date: Wed, 06 Dec 2017 13:25:10 +
: From: Adrien Grand
: Reply-To: dev@lucene.apache.org
: To: Lucene Dev
: Subjec
Karl: reviewing recent commits I notice you've been backporting a handful
of (what appear to be) "Improvements" / "Features" to branch_6x ... but
branch_6x is too old for feature releases -- so i'm confused as to the
point ofthese commits?
If these jira's/changes are misslabeled and are actaul
: In the BM25 case, scores would decrease in some situations with very
: high TF values because of floating point issues, e.g. so
: score(freq=100,000) would be unexpectedly less than
: score(freq=99,999), all other things being equal. There may be other
: ways to re-arrange the code to avoid this
: That’s a very odd drop. The only lucene commit that happened around
: then is LUCENE-8018, which really shouldn’t be making a difference to
: query performance. And there’s no change to the PhraseQuery graphs.
Each run records the Git SHA it was run against -- the dip that's been
noted was
: DistributedUpdateProcessor (or what I call DURP for short) is very
: complex. One aspect of the complexity is that it appears it tries to
: support SolrCloud and classic Solr. Do we still need it to support classic
: Solr? When/why? Forever?
Part of the issue here is that DUP is responsible
: SuppressLocaleRandomization(locale="en-US", reason="Derby doesn't work
: with complex locales, see issue ...")?
that would be cool ... with 'reason' & 'locale' as optional, both
defaulting to "" (whch for Locale should result in Locale.ROOT IIUC?)
For consistency with existing annotations a n
: I've been asked today about whether there is a way to express a query like:
:
: q="foo bar baz"
: My tentatively answer based on the code is that mm (min should match)
: only applies to Boolean queries (clauses), so there is no way to mix
that is correct -- minNrShouldMatch is only a BQ conc
: I didn't forget, precisely. I used git commit -a and it didn't pick up the
: file (for some reason as yet undetermined) and I didn't catch it. Fixed
: now (via explicit git add).
"-a" is not designed/intended to pick up new files -- as documented...
-a, --all
Tell the command to auto
: Since August 17th, This test seems to have started failing multiple times
: a day, on 7x and master, on diff jvms and OSs -- prior to Aug17 it rarely
: failed more then once a week.
The following commits seem both topical & suspiciously timed relative to
the to the code being tested and when
Since August 17th, This test seems to have started failing multiple times
a day, on 7x and master, on diff jvms and OSs -- prior to Aug17 it rarely
failed more then once a week.
: Date: Thu, 31 Aug 2017 15:37:21 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
:
I haven't duf into this, but it's almost certainly related to
SOLR-11209...
https://issues.apache.org/jira/browse/SOLR-11209
: Date: Thu, 31 Aug 2017 16:28:16 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-
i can write a git bisect
script to verify
https://issues.apache.org/jira/browse/SOLR-10628
: Date: Wed, 23 Aug 2017 18:26:05 -0700 (MST)
: From: Chris Hostetter
: To: dev@lucene.apache.org
: Subject: Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+181) -
: Build # 20364 - Still
: FAILED:
org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest.testUpdateDistribChainSkipping
:
: Error Message:
: Tests must be run with INFO level logging otherwise LogUpdateProcessor isn't
used and can't be tested.
This failure reproduces for me when i run the whole test suite
Lucene.Net is a fully distinct Apache project with completely
independent developer/user communities, mailing lists, source code
repository, and releases...
https://lucenenet.apache.org/community.html
: Date: Mon, 24 Jul 2017 21:56:17 +0530
: From: rohit kumar
: Reply-To: dev@lucene.apache
: So, my overall point is that if A) we agree that we want to deprecate
: Trie* numeric fields, and B) we want to hold up the 7.0 release until
: that's done, it's more than just updating the example schemas if we
: want to ensure a quality app for users. We still need to fix the tests
: and also
: Here’s my issue with that approach. Say I commit something that would be
: released with 7.0 but obviously, I also commit to master at this point.
: Going with your approach here are the fix versions I’ll end up with on
: the JIRA - master (8.0), 7.1, and 7.0.
:
: This confuses me, as anythi
: I think my confusion stems from the smoke checker allowing ant 1.8 OR 1.9,
: then.
:
https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/smokeTestRelease.py#L193
That seems bad to me - the explicit check for the minimum version of ant
(used to make the jars) is suppose to be d
FWIW: I'm seeing a bunch of test failures that look suspiciously related
to this commit i'll post details in jira.
: Date: Wed, 21 Jun 2017 15:26:00 -
: From: da...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: [1/2] lucene-solr:master: SOLR-82
Karl: this broke precommit due to broken documentation links
: Date: Wed, 31 May 2017 11:56:30 -
: From: kwri...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: [1/2] lucene-solr:master: LUCENE-7853: Add methods for people to use
: who know their
Uwe: I've filed SOLR-10728 to track this since i'm not 100% clear on what
you you feel the 'right' fix for all of this is.
: Date: Mon, 22 May 2017 20:38:03 +0200
: From: Uwe Schindler
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: RE: License headers for solr-ref-gui
: Hoss and I talked about this while we were developing all the tools
: and processes, but while we agreed they should have the license
: headers, I forget what we decided to do - I thought the conversion was
: going to add them, but I'll have to ask him, which i'll do and get
: them added.
yeah,
FWIW: none of them reproduce for me with jdk9-ea+170 ... i don't have a
copy of ea+168 to test with.
: Date: Fri, 19 May 2017 19:23:11 -0400
: From: Steve Rowe
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Cc: Uwe Schindler
: Subject: Re: [JENKINS-EA] Lucene-Solr-master-Linu
Thanks Jan,
I have re-educated my emacs setup to ensure it realizes that my
'no-fucking-tabs' hook should be applied to css and javascript as well.
: Date: Sun, 21 May 2017 08:58:43 + (UTC)
: From: jan...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subje
NOTE: I'm -0 to this change, see detailed comments in SOLR-10644
: Date: Tue, 9 May 2017 11:00:33 + (UTC)
: From: jan...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr:solr10644: SOLR-10644: solr.in.sh installed by install
: script sh
David: doesn't this same bug affect /schema/fieldType ?
Can't large="true" be specified on fieldType as a default for all fields
that inherit from that type?
Also: what about /schema/dynamicfields ?
: Date: Tue, 18 Apr 2017 21:02:12 + (UTC)
: From: dsmi...@apache.org
: Reply-To: dev@lu
: For me I use "closed" to figure out if an issue was just committed or if
: there is already a release out there. So to me it is natural to close
And to continue that line of thinking: the reason this should be important
is so that we don't inadvertantly "tack on" any work/tweaks to issues th
https://issues.apache.org/jira/browse/SOLR-10338
: Date: Sun, 2 Apr 2017 23:05:59 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+162) - Build #
: 19294 - Still Unstab
Uwe: can you please udpate the confluence javadoc macros to point to 6.5.0?
https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Javadoc+Links+Work
(Hopefully this is the last time we every have to ask you to do this!!)
: Date: Wed, 29 Mar 2017 09:48:04 -0500
: From: Cassandra Targe
https://issues.apache.org/jira/browse/SOLR-10362
: Date: Fri, 24 Mar 2017 15:55:28 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3138 -
: Unstable!
:
: Bui
: But that also makes it important that any committer is given good tools
: to make sure her edits look good. I hope Asciidoc is more standardised
: than Markdown, else your choice of tooling may ultimately decide whether
: your edits look good or bad.
Asciidoc(tor) is much more standardized a
: *) should there be LICENCE on the Github repo if you want people to
: play/experiment/contribute ideas?
I'm not sure that's really neccessary at this point -- so far all of the
contributions have been from existing committers, and we (probably?) don't
want to take on any (new) significant con
: If you don't like the limit for your specific test: use
: @SuppressFileSystems annotation to suppress it.
:
: But it is really insane for a unit test to use so many index files,
: and it is important to reproduce such bugs when they do happen.
i'm not disagreeing with the value of HandleLimitF
The exception is being thrown by org.apache.lucene.mockfile.HandleLimitFS,
so the OS level utlimit isn't relevant (as long as it's greter then 2048,
hardcoded in TestRuleTemporaryFilesCleanup)
With the test creating 2 diff indexes, that means each index index gets an
effective max open files
: > WTF happened here
: >
: > 1) Did we lose anything ?
: > ... IIUC we only lost one commit (which Noble did again?)
:
: IIUIC the only way to be sure is to compare the history from someone’s
: local repo that still hasn’t been updated with the (possibly) truncated
: history from GitHub.
WTF happened here
1) Did we lose anything ?
... IIUC we only lost one commit (which Noble did again?)
2) I thought the main apache repo was configured to reject forced
pushes
: Date: Thu, 2 Mar 2017 11:09:37 + (UTC)
: From: no...@apache.org
: Reply-To: dev@lucene.apache.org
: T
XT
: >>
: >> Is that a veto? If not, does a voting, to determine what works for most,
: >> make sense?
: >>
: >>
: >>
: >> Regards,
: >>
: >> Ishan
: >>
: >>
: >>
: >> On Mon, Jan 30, 2017 at 11:43 PM, Uwe Schindler wrote:
: &g
Some historic context: https://issues.apache.org/jira/browse/LUCENE-5143
Keep in mind that things like the solr ref guide and pylucene releases
don't do "per-release" KEY files, so completley eliminating those URLs
would require a change to those process.
on the flip side: see Uwe's comment in
: It sends mails to the dev@lao mailing list in HTML (which I really
: like!), but you can still configure the ones sent to yourself as TXT
: only. Not sure how to change the mailing list ones to be text only!
I agree with ishan -- the new HTML formatted mails to the list are pretty
much impo
Erick: see discussion in SOLR-1915.
The gist of the argument in favor of plaintext as a default was that the
plain text is easier to read for humans in a browser, and that humans in a
browser are the primary consumers of debug.explain.
https://issues.apache.org/jira/browse/SOLR-1915?focusedCom
see SOLR-10013 / LUCENE-7649
: Date: Fri, 20 Jan 2017 21:18:06 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+152) - Build #
: 2703 - Still Unstable!
:
: Build: https:/
: I am trying to switch from using the SolrJ Embedded Server to the
: SolrJettyTestBase in my Junit tests. However, I am getting the following
: error:
:
: java.lang.Exception: Assertions mismatch: -ea was not specified but
: -Dtests.asserts=true
...
: I reached out to the Solr User list,
David: something went haywire with your backport -- it added a 7.0.0
section to CHANGES.txt, which is breaking the smoketester jenkins
: Date: Mon, 5 Dec 2016 21:21:19 + (UTC)
: From: dsmi...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr
Alan & Mikhail...
Should we add HttpClientContext's constructor to forbidden APIs list and
force internal code to use the helper APIs to prevent (test) bugs like
this in the future?
: Date: Mon, 10 Oct 2016 09:22:51 + (UTC)
: From: m...@apache.org
: Reply-To: dev@lucene.apache.org
: To:
It's not immediately obvious to me why these collection deletions can't be
done in an @After method -- but if they need to live in each test method
can we at least have an @After method that asserts no collections exist
(via a STATUS call) so if someone writes a new test method but forgets to
: Sorry, this is not okay and I feel strongly about this. Very deliberate
: care should be taken to our SolrJ dependencies since they are used in many
: environments, and dependencies there add a burden on anyone using Solr.
+1
We should really be striving to make solrj completely devoid of
de
to modify the
: work itself if, for example, it mentions the various licensing options
: in the source headers.
:
:
: On Wed, Sep 21, 2016 at 8:52 PM, Chris Hostetter
: wrote:
: >
: > : then, who looks at those files anyway... Let's leave it as is if Chris
: > : says there was
: then, who looks at those files anyway... Let's leave it as is if Chris
: says there was a discussion about it in the past.
I could be wrong ... it's not like i looked very hard in the archives to
try and find any such discussion ... It's possible my mind is just filling
in the gaps with my ow
I'm having a feeling of deja-vu.
I thought this was discussed a long time ago, and the concensus was that
what we keep in ./licenses should be the *entire* LICENSE file from each
dependency, verbatim -- regardless of if/when it's offered under multiple
licenses -- so that if someone says "XYZ
FWIW: SOLR-9490 Is a pretty nasty bug for most BoolField users.
We should probably consider a rapid 6.2.1 release.
https://issues.apache.org/jira/browse/SOLR-9490
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-mail:
New jira to track this: https://issues.apache.org/jira/browse/SOLR-9490
: Date: Thu, 8 Sep 2016 18:41:31 +0530
: From: Pavan S Shetty
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: Re: Binary Response Writer Issue in solr version 6.2.0
:
: Thanks Alexandre...
:
: Yes,
: +1, we should remove the Lucene doc values based queries.
Whoa...
Wouldn't that completley kill ~50% of the utility of having updatedable
DocValues support in Lucene?
Having an updatable field you can sort on is handy, but if the only way to
search/filter on the same effective (updated) val
: I am not against having multiple documentation branches -- I am *for*
: that. I am against emulating our current source code practice of needing
: to commit twice (two branches) for most things. I think that should be the
: exception, not the rule. Only during a new dot-zero release would we
: Is there anyway to maintain inbound links to confluence pages with the new
: system? I'm just thinking about all the user group questions, stackoverflow
: Qs, and the like that link to cwiki pages.
:
: Is it possible to setup the right redirects for cwiki pages into the new
: system?
That shou
: First, I'm not about to second-guess this. I wouldn't like to lose the
: ability to download a full doc to search offline, but it looks like
: this solution allows that since there is a PDF version after all.
I also like being able to officially "release" the guide, and doing so via
PDF will s
Heh ... this looks like an incredibly rare fluke.
QueryUtils.check(q) calls QueryUtils.checkHashEquals(q) which does 2
main things:
1) QueryUtils.checkEquals(q,q)
- verify q equals itself
- verify q.hashCode returns the same thing twice
2) make a "whacky" Query that only equals itself and
Thanks dawid! ... beat me to it.
: Date: Thu, 07 Jul 2016 08:16:44 -
: From: dwe...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: [1/2] lucene-solr:master: Added tests.awaitsfix to properties passed
: to forked JVMs in tests. Added a little info a
Over in SOLR-9180 i've worked up a patch with a bunch of new tests, some
of which are disabled via @AwaitsFix because of bugs i uncovered while
writting them that i wanted to go back and reinvestivate later.
Example...
public void testAugmenters() throws Exception {
...
}
@AwaitsF
: : I ran this test before I committed the backport, but it succeeded then.
: : I beasted it on current branch_5_5 and 49/100 seeds succeeded.
:
: one of the things that cahnged as part of LUCENE-7132 was that i made all
: the BQ related tests start randomizing setDisableCoord() ... so you mig
: I ran this test before I committed the backport, but it succeeded then.
: I beasted it on current branch_5_5 and 49/100 seeds succeeded.
one of the things that cahnged as part of LUCENE-7132 was that i made all
the BQ related tests start randomizing setDisableCoord() ... so you might
be see
something seriously fucked up with jenkins tests timing out the past few
days ... not sure if i caused it, so i'm going to be paranoied and assume
i did -- details: https://issues.apache.org/jira/browse/SOLR-9189
: Date: Mon, 6 Jun 2016 15:15:50 + (UTC)
: From: Apache Jenkins Server
: Rep
101 - 200 of 1146 matches
Mail list logo
