If I were talend, I'd immediately start publishing to maven central. If I
were the developer who built the schema APIs, I would never have used
restlet to begin with.
On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, wrote:
> I was thinking the same. Because GitHub does not cache the downloaded
>
I shall revert the changes and work on a solution
On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski wrote:
> > I don't think it is along the Apache way to revert somebody's commit
> without an explicit permission to do so
> Interesting, I made the Devil's Advocate argument above with the
> Apache
Thanks for the feedback everyone!
I'll get us started off with the docker and SolrJ tests. We can revisit
after a few weeks and see how it has gone.
- Houston
On Fri, Sep 18, 2020 at 2:28 PM Atri Sharma wrote:
> +1.
>
> Ability to run tests in Github actions should help prevent a ton of build
> I don't think it is along the Apache way to revert somebody's commit without
> an explicit permission to do so
Interesting, I made the Devil's Advocate argument above with the
Apache Way specifically in mind.
"Community over Code" comes up most often in terms of navigating
interpersonal
I thought we were talking about reverting your own commits, not someone
else’s...
On Fri, Sep 18, 2020 at 12:31 PM Dawid Weiss wrote:
> I don't think it is along the Apache way to revert somebody's commit
>
> without an explicit permission to do so... Not that I would personally
>
> mind if
I was thinking the same. Because GitHub does not cache the downloaded artifacts
like our jenkins servers.
It seems to run it in a new VM or container every time, so it downloads all
artifacts. If I were Talend, I'd also block this.
Uwe
Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss
I don't think it's http/https - I believe restlet repository simply
bans github servers because of excessive traffic? These URLs work for
me locally...
Dawid
On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
LONDON) wrote:
>
> This sounds vaguely familiar. "http works, https does
I don't think it is along the Apache way to revert somebody's commit
without an explicit permission to do so... Not that I would personally
mind if somebody did it for me.
On Fri, Sep 18, 2020 at 9:06 PM Tomás Fernández Löbbe
wrote:
>
> Sometimes Jenkins may take hours to take your commit, may
Jason:
I wouldn’t object to reverting immediately. It’s a courtesy to give someone a
chance to fix it themselves rather than unilaterally revert is all.
> On Sep 18, 2020, at 3:05 PM, Tomás Fernández Löbbe
> wrote:
>
> Sometimes Jenkins may take hours to take your commit, may fail in the
Sometimes Jenkins may take hours to take your commit, may fail in the
middle of your night, may not fail consistently, etc. That's why I don't
think giving specific timeframes makes sense, but yes, as soon as you
notice it's failing, it's either fix immediately or revert IMO.
On Fri, Sep 18, 2020
> If it’s inadvertently added, we either fix it within an hour or so or revert
> the offending commit
> I don't want to set specific time frames,
To play Devil's Advocate here: why wait even an hour to revert a 100%
test failure? Reverts are usually trivial to do, unblock others
immediately,
+1.
Ability to run tests in Github actions should help prevent a ton of build
breakages.
Thanks for leading this, Houston!
On Fri, 18 Sep 2020 at 21:24, Houston Putman
wrote:
> Good point on the reference_impl branch. Eventually that's the goal, but
> given there's not a timeline for that to
> The docker tests will not be run on any PRs that don't touch bin/solr,
solr/packaging or solr/docker.
Sounds good, then!
On Fri, Sep 18, 2020 at 11:44 PM Anshum Gupta
wrote:
> I like the idea as I really feel Github actions provide a ton of value.
>
> It doesn't have to be a blocker for all
I like the idea as I really feel Github actions provide a ton of value.
It doesn't have to be a blocker for all cases but for it to just run would
be great. We don't really lose anything there.
On Thu, Sep 17, 2020 at 8:56 AM Houston Putman
wrote:
> Thought I'd make this a thread instead of a
Yeah I'm definitely in favor of adding tests to GitHub actions. Even if
the action reports a failure, presumably we could opt to commit anyway if,
for example, we know that the test that failed is totally unrelated to the
work being committed and/or the failing test is related to some other known
I believe these failures are associated to
https://issues.apache.org/jira/browse/SOLR-14151
• FAILED: org.apache.solr.pkg.TestPackages.classMethod
• FAILED:
org.apache.solr.schema.PreAnalyzedFieldManagedSchemaCloudTest.testAdd2Fields
• FAILED:
I think this is a good idea. In general, I'm +1 on improving PR validations
as much as possible, and as Houston says, we can always remove them later
if it's not helping. I also agree with David in his Jira comment that even
more important than this is to have the tests running on Jenkins, but I
This sounds vaguely familiar. "http works, https does not work" and
https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
From: dev@lucene.apache.org At: 09/18/20 10:01:29To: dev@lucene.apache.org
Subject: Re: restlet dependencies
I don't think it is, sadly.
+1 to not depending on Docker for local tests.
I do not wish to derail this thread — but re: reference branch, doesn’t it
have a bunch of tests disabled?
On Fri, 18 Sep 2020 at 03:53, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> > It would be great to run all the tests every time,
+1 to be more strict about the order of operators. That's a bug fix imo.
Le jeu. 17 sept. 2020 à 08:58, Dawid Weiss a écrit :
> Just so that it's not overlooked. I suggest a cleanup of the
> (flexible?) query parser syntax in LUCENE-9528.
>
> In short, the current javacc code is a tangled mess
Good point on the reference_impl branch. Eventually that's the goal, but
given there's not a timeline for that to be merged yet I think this is a
good stop-gap. It's a few minutes of work to get these PR actions written,
so I feel like there is little downside. And we can always remove them when
When I said temporary, I meant 3-4 hours. Definitely not more than that.
IMO we should just roll back offending commits if they are easily
identifiable. I agree with you — we all have been guilty of breaking builds
(mea culpa as well). The bad part here is the longevity of the failures.
On Fri,
HdfsAutoAddReplicasTest is just wrapping AutoAddReplicas tests with HDFS
last I checked. There haven't been any HDFS changes lately that I've seen.
So what changed in regards to AutoAddReplicas? Based on
bq. IMO if a temporary instability is to be introduced deliberately, it should
be published on the list
Actually, I disagree. Having anything in the tests that fail 100% of the time
is just unacceptable since it becomes a barrier for everyone else. AFAIK, if
the problem can be identified to a
IMO if a temporary instability is to be introduced deliberately, it should
be published on the list. If it’s inadvertently added, we either fix it
within an hour or so or revert the offending commit.
On Fri, 18 Sep 2020 at 20:26, Erick Erickson
wrote:
>
http://fucit.org/solr-jenkins-reports/failure-report.html
HdfsAutoAddReplicasTest failing 100% of the time.
TestPackages.classMethod failing 100% of the time
3-4 AutoAddReplicas tests failing 98% of the time.
Is anyone looking at these? I realize the code base is changing a lot, and some
>You could avoid (some of?) these problems by supporting /(?i)foo/ instead
of /foo/i
That would avoid our parsing dilemma but brings some other concerns. This
inline syntax can normally be used to selectively turn on case sensitivity
for sections of a regex and then turn it off with (?-i).
We
I don't think it is, sadly.
https://repo1.maven.org/maven2/org/restlet
The link you provided (mvnrepository) aggregates from several maven
repositories.
D.
On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
wrote:
>
> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven
https://mvnrepository.com/artifact/org.restlet.jee/org.restlet.ext.servlet
On Fri, 18 Sep, 2020, 2:15 pm Ishan Chattopadhyaya, <
ichattopadhy...@gmail.com> wrote:
> Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
> these days. Can we confirm and switch to that? Sorry,
Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
these days. Can we confirm and switch to that? Sorry, if that's not the
case.
On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, wrote:
> Just FYI: can't get PR builds on github to work recently because of this:
>
> > Could not
Just FYI: can't get PR builds on github to work recently because of this:
> Could not resolve all files for configuration ':solr:core:compileClasspath'.
350 > Could not download org.restlet.ext.servlet-2.4.3.jar
(org.restlet.jee:org.restlet.ext.servlet:2.4.3)
351 > Could not get resource
> If they try to use any other options then 'i' we throow a ParseException
+1. Complex-syntax parsers should throw (human-palatable) exceptions
on syntax errors. A lenient, "naive user" query parser should be
separate and accept a very, very
rudimentary query syntax (so that there are literally
Hi Chris,
> Because if you can adjust your parser syntax, this literallyly just
> becomes: ' field:"foo bar"~N ' ... where N is the positionIncrementGap
> on your analyzer ... OR ... ' field:"foo bar" ' ... if you call
> setPhraseSlop on your QueryParser.
Yes - correct. This would be
33 matches
Mail list logo
