be more supportive of
this functionality?
Any suggestions or comments greatly appreciated. Thanks for your thoughts
and time.
Cheers,
Jason Gerlowski
gerlowsk...@gmail.com
[1] http://plg.uwaterloo.ca/%7Eftp/mt/TechReports/CS-94-30/
http://plg.uwaterloo.ca/~ftp/mt/TechReports/CS-94-30/
[2
these fixtures. To an amateur, it looks like some static
fields in LTC aren't being initialized. It's hard to tell whether I should
consider this a bug in the class, or whether I'm using it incorrectly.
Thanks for any help/insight you can offer!
Best,
Jason Gerlowski
(I can follow-up with code-snippets
-- be specific, provide code examples.
Dawid
On Wed, Nov 12, 2014 at 4:06 PM, Jason Gerlowski gerlowsk...@gmail.com
wrote:
Hi all,
I'm seeing NPE's when calling static methods on LuceneTestCase (without
extending it).
I'm trying to write tests for a few classes that interact
Is this documented anywhere outside of the JIRAs you mentioned Erick
(or anyone else)? I can only speak for myself, but I don't think I
would've expected/caught that as a potential Solr consumer, even
though it is working as designed. If it doesn't make sense to
actually this; ensuring this is
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
Hi all,
I've been playing around with Solr's Blob Store the last few days, and
am looking to delete a blob out of the Blob store. Looking around a
bit, I couldn't find any sort of "delete" API for blobs (I mainly
looked at SOLR-6787, and
Hi all,
Mike Drob, Steve Rowe, and myself recently ran into a small hiccup on
LUCENE-5822 that was caught by the "nightly-smoke" ant task, but not
by the more standard "precommit" or "test" targets that we recommend
contributors run before uploading a patch
I noticed recently that arg validation/parsing/help-text for the
"create", "delete", "auth", "zk", etc. commands makes up a huge chunk
of the (bin/solr) scripts. (Some 600 lines by a quick count!)
This is a shame, since that logic is duplicated across two
platform-specific scripts.
I'm not
gt;>> code between the *nix, and the windows scripts but due to lack of bandwidth,
>>> that was never done.
>>>
>>> It'd be great to get a patch on the same and have this move out of the bin
>>> scripts altogether. Feel free to create a JIRA and start worki
Yikes, that seems obvious in hindsight. I've verified that does the
trick. Thanks Uwe!
On Wed, Jun 14, 2017 at 3:29 PM, Uwe Schindler <u...@thetaphi.de> wrote:
> Ant compile-test?
>
> Am 14. Juni 2017 21:09:36 MESZ schrieb Jason Gerlowski
> <gerlowsk...@
Hey all,
Is there an ant-command we support for compiling *all* files
(including tests) at once.
My understanding is that "ant test" compiles each test package right
before it's run. This is occasionally a pain, as test runs can
occasionally fail halfway through because of a compilation error
+1 to @since tags.
And an extra +1 to start adding the version to new @deprecated tags.
And maybe even to do some digging in git so the version can be added
to things that are already deprecated. I ran into this exact issue a
few times in the last months.
On Mon, Oct 9, 2017 at 12:04 PM, Shawn
n, Oct 22, 2017 at 9:47 PM, Varun Thacker <va...@vthacker.in> wrote:
>> I'd prefer 1>
>>
>> On Sun, Oct 22, 2017 at 7:39 PM, Jason Gerlowski <gerlowsk...@gmail.com>
>> wrote:
>>>
>>> Hey all,
>>>
>>> Was doing some poking ar
Hey all,
I was playing around with SolrJ a bit this weekend, and the
getRequestUrl() on SolrJ's response objects caught my eye:
https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/solrj/src/java/org/apache/solr/client/solrj/response/SolrResponseBase.java#L82
on, Oct 23, 2017 at 7:36 PM, Jason Gerlowski <gerlowsk...@gmail.com> wrote:
> Thanks for the feedback (and context/history) guys. I've created
> SOLR-11530 (https://issues.apache.org/jira/browse/SOLR-11530) to keep
> track of this.
>
> You're right Cassandra, switching the snippe
Hi Cassandra,
I'd like to put in a tentative vote for getting SOLR-11032 in for the
next ref-guide release. It has a much-needed refresh of the "Using
SolrJ" page, which has fallen a few releases behind.
I say "tentative" above because I don't think anyone has taken a look
at reviewing the
Hey all,
I was testing some Collections APIs the other day, and noticed a
curious response format for the SPLITSHARD and MIGRATE commands.
Both have a large number of near-duplicate responseHeader sections
with different QTimes. Is there a reason all these sections are being
returned back to
Welcome Nhat!
On Tue, Jun 19, 2018 at 10:10 AM, Varun Thacker wrote:
> Congratulations and welcome Nhat!
>
> On Tue, Jun 19, 2018 at 10:16 AM, Alan Woodward
> wrote:
>
>> Welcome Nhat!
>>
>>
>> On 18 Jun 2018, at 21:41, Adrien Grand wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Nhat
Hey all,
Was doing some poking around the ref-guide this weekend. I noticed
that the output snippets given with the API documentation is split
about 50/50 between xml and json. Few of the examples contain an
explicit "wt" parameter. With the default "wt" format switching to
json in 7.0, this
It sounds like the recommendation in this thread is to _always_ use
"ant beast" instead of "tests.iters". Is there _any_ case where
"tests.iters" should be preferred? If not, should we remove support
for "tests.iters" to remove any ambiguity? (Especially since this has
come up on the list a few
too useful to remove.
>>
>> Best,
>> Erick
>>
>>
>> On Mon, Jan 15, 2018 at 7:56 AM, Jason Gerlowski <gerlowsk...@gmail.com>
>> wrote:
>>> It sounds like the recommendation in this thread is to _always_ use
>>> "ant beast" i
t;>>>
>>>>> Dawid
>>>>>
>>>>> On Thu, Feb 8, 2018 at 6:04 PM, Adrien Grand <jpou...@gmail.com> wrote:
>>>>> > Welcome Jason!
>>>>> >
>>>>> > Le jeu. 8 févr. 2018 à 18:03, David Smiley <david.w.smi...@gm
I don't have strong opinions about what we do with our existing flaky
tests. I think re-running failures before commit might theoretically
catch more bugs than ignoring the test outright, but with all the
noise and how standard it is to need to rerun tests I'd be surprised
if the numbers are all
You can also tell the test framework to temporarily skip the bad apple
tests with the flag "-Dtests.badapples=false", which is sometimes
useful. Just an FYI.
Jason
On Fri, Aug 24, 2018 at 11:14 AM Erick Erickson wrote:
>
> One other thing:
> There are two sources of randomness. the difficult
+1 from me
On Thu, Aug 30, 2018 at 3:33 PM Erick Erickson wrote:
>
> +1 from me. One of my long-term goals is to gradually work through a
> lot of Solr/Lucene code and get the warnings out. At that point I
> fully intend to make warnings fail on clean code so we don't
> backslide.
> On Thu, Aug
I authored the recent change you're commenting on. I agree with your
points; my only defense is consistency. Several other nearby
assertions used the older try-catch based setup.
I'll fix the spot you objected to, and file a JIRA around cleaning
this up more broadly. Having this elsewhere in
To toss my two cents in, I agree with Hoss's point generally. Burying
important things that users may care about in "Other Changes" makes
them harder to discover, and we should start double-checking ourselves
on that.
But as for test-fix changes specifically, if the main purpose of
CHANGES.txt
Congrats and welcome Gus!
On Thu, Nov 1, 2018 at 10:13 AM Gus Heck wrote:
>
> Hi all,
>
> Thanks for inviting me to be a committer!
>
> Bio:
> I've enjoyed programming computers for over 30 years now, starting on an
> Timex Sinclair 2k (with 16k expansion pack!). Until 2002 programming was a
>
Congrats!
On Wed, Jan 2, 2019 at 2:09 PM Kevin Risden wrote:
>
> Congrats!
>
> Kevin Risden
>
> On Wed, Jan 2, 2019 at 1:36 PM Anshum Gupta wrote:
> >
> > Congratulations, Cassandra!
> >
> > On Sun, Dec 30, 2018 at 11:38 PM Adrien Grand wrote:
> >>
> >> Every year, the Lucene PMC rotates the
Server,
> or is there a different base class for such tests?
>
> On Tue, Mar 26, 2019 at 2:55 PM Jason Gerlowski wrote:
>>
>> Hi Thomas,
>>
>> I see what you mean; the utilities used by that test as-is rely on
>> XML. If you want to send the atomic-updat
Hi Thomas,
I see what you mean; the utilities used by that test as-is rely on
XML. If you want to send the atomic-update via Javabin, the best
option is probably to write a small testcase using SolrJ. Javabin is
the default wire format in SolrJ, so it should do what you want.
If you haven't
Congrats Ignacio!
On Mon, Mar 4, 2019 at 7:17 AM Martin Gainty wrote:
>
> ¡Bienvenidos Ignacio!
>
>
> From: Dawid Weiss
> Sent: Monday, March 4, 2019 6:45 AM
> To: dev@lucene.apache.org
> Subject: Re: Welcome Ignacio Vera to the PMC
>
> Welcome, Ignacio!
>
> On
Please vote to release the Solr Ref Guide for 7.7.
The PDF artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.7-RC0/
$ cat apache-solr-ref-guide-7.7.pdf.sha512
t; On Fri, Mar 8, 2019 at 9:03 AM Tomás Fernández Löbbe
> wrote:
>>
>> +1
>>
>> On Thu, Mar 7, 2019 at 11:14 AM Anshum Gupta
>> wrote:
>>>
>>> +1
>>>
>>> Thanks for doing this, Jason!
>>>
>>> Anshum
&
I have no idea how easy/hard/painful that change would be, but in
theory I'd be in favor of seeing it done. The problem is easily
solvable with mail-filters, but relying on that as a solution makes
everyone go through the same work. Also, I've found that they
occasionally break on project
Still looking for one more vote to finish (or respin) the release.
Please take a look if you can find the time!
On Wed, Mar 6, 2019 at 3:34 PM Cassandra Targett wrote:
>
> +1. Thanks Jason for running this release.
>
> Cassandra
> On Mar 4, 2019, 9:29 AM -0600, Jason Gerlo
Hey Alan,
I just committed a minor inconsequential bugfix
(1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0. I didn't
realize I was cutting it so close to your work on cutting RC1, but
from commits I see you made this morning preparing for the RC I
suspect I cut things _very_ close and
Hey all,
With 7.7 out the door, I wanted to get the ball rolling on a
corresponding ref-guide release. If anyone has doc edits for 7.7 that
they've been meaning to get to, now's a great time to start - you'll
still have a few days to get them in. I want to give time for people
to get any
Here's another (non-binding) +1.
SUCCESS! [1:03:20.975193]
On Wed, Feb 6, 2019 at 4:55 PM Tim Allison wrote:
>
> +1 (non-binding)
>
> Thank you!
>
> On Wed, Feb 6, 2019 at 4:19 PM Nicholas Knize wrote:
> >
> > +1 SUCCESS! [1:00:01.156649]
> >
> > On Wed, Feb 6, 2019 at 10:10 AM Uwe Schindler
+1, Looks good to me.
On Mon, Jun 3, 2019 at 12:38 AM Anshum Gupta wrote:
>
> +1
>
>
> On Fri, May 31, 2019 at 7:24 AM Cassandra Targett wrote:
>>
>> Please vote to release the Solr Reference Guide for 8.0.
>>
>> The PDF artifacts can be downloaded from:
>>
+1 LGTM
On Fri, Jun 14, 2019 at 5:44 PM Gus Heck wrote:
>
> Noticed one thing that probably isn't enough to re-spin, but I'll fix for
> future:
>
> on Aliases page
>
> an alias must not refer to a Routed Alias (see below)
>
> shows up at the bottom of the page, and should say (see above) or
Congrats and welcome!
On Mon, Jun 24, 2019 at 4:59 AM Alan Woodward wrote:
>
> Congratulations and welcome!
>
> On 24 Jun 2019, at 08:42, Shalin Shekhar Mangar
> wrote:
>
> Congratulations and welcome Munendra!
>
> On Fri, Jun 21, 2019 at 3:12 PM Ishan Chattopadhyaya
> wrote:
>>
>> Hi all,
Congrats Michael!
On Tue, May 14, 2019 at 7:57 AM Shalin Shekhar Mangar
wrote:
>
> Congratulations and welcome Michael!
>
> On Tue, May 14, 2019 at 12:42 AM Dawid Weiss wrote:
>>
>> Hello everyone,
>>
>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>
>> Many of you
sue using EmbbededSolrServer, i didn't had time the last few weeks,
> should i open a new issue for this?
>
> I think backporting this to 7.x is also a good idea!
>
> On Tue, Mar 26, 2019 at 3:46 PM Jason Gerlowski wrote:
>>
>> I'm only passingly familiar with EmbeddedSolrServer. But
quire a bug fix 7.7.1 release as well.
> > >> > In the interest of time, I propose rolling back SOLR-12739 which
> > >> > caused these issues. We can re-introduce it with proper fixes for the
> > >> > related issues in 8.1.
> > >> >
> > >>
Welcome Tomoko and congratulations!
On Tue, Apr 9, 2019 at 6:34 AM jim ferenczi wrote:
>
> Welcome Tomoko!
>
> Le mar. 9 avr. 2019 à 12:19, Ishan Chattopadhyaya
> a écrit :
>>
>> Yokoso, Tomoko-san! Congratulations..
>>
>> On Tue, Apr 9, 2019 at 2:28 PM Christine Poerschke (BLOOMBERG/ LONDON)
Congratulations and welcome Atri!
On Wed, Sep 18, 2019 at 6:24 AM Shalin Shekhar Mangar
wrote:
>
> Congratulations and welcome Atri!
>
> On Wed, Sep 18, 2019 at 3:12 AM Adrien Grand wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>
>> If you are
a of squash-merging from PR branch since (I believe) the
>> commit will then have the credit of the contributor which then shows up in
>> his/her stats on GH which is nice.
>>
>> Jan Høydahl
>>
>> > 17. sep. 2019 kl. 16:17 skrev Jason Gerlowski :
>> >
>>
Hey all,
I've hit a small snag reviewing a few PRs on github recently. Wanted
to see if anyone has any suggestions for my workflow:
I’ve found myself in the position a few times where I want to add a
few small changes to a contributor’s PR…either to help them with a
piece they haven’t gotten to
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?
re: issues on github. There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that
this as an optional checklist item in the PR template
that was recently added.
Still curious about other approaches though if anyone has suggestions.
[1]
https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork
On Tue, Sep 17, 2019 at 10:12 AM Jason
Hi Mikhail,
I'm having trouble understanding the exact syntax you're proposing.
Is there a jira where the syntax is described in a little more detail?
If not, would you care to put together a writeup on a jira somewhere?
It's hard (for me at least) to weigh in as things are currently.
Best,
To throw my 2 cents in on SOLR-13647.
Yes, users can fix the problem trivially by updating their solr.in.sh
_if_ they're aware of the issue. And we recommend all users examine
their config carefully when upgrading Solr versions, so users _should_
be aware of the issue. But at the same time, the
Hey Ignacio,
I think in the course of cutting the 8.2 release, you might've broken
precommit on master. I'm getting the following error consistently:
[xmlproperty] [Fatal Error] solr.rdf:685:5: The element type "release"
must be terminated by the matching end-tag "".
...
BUILD FAILED
When I
+1. That all sounds good to me. Excited to see some streamlining here.
On Fri, Sep 20, 2019 at 3:46 PM Cassandra Targett wrote:
>
> Thanks everyone, by the way, for the encouragement and feedback here.
>
> For next steps, how do folks feel about making the change to stop voting on
> the PDF
Hi Raphael,
Welcome and thanks for taking an interest in helping out! Shawn's
pointers above are all good for getting started. If there's any other
information you need, let us know.
You know best what you want to get involved with. But if you're
interested in QA and are interested in the
Congratulations!
On Thu, Nov 14, 2019 at 11:58 AM Gus Heck wrote:
>
> Congratulations and welcome :)
>
> On Thu, Nov 14, 2019 at 11:52 AM Namgyu Kim wrote:
>>
>> Congratulations and welcome, Houston! :D
>>
>> On Fri, Nov 15, 2019 at 1:18 AM Ken LaPorte wrote:
>>>
>>> Congratulations Houston!
> and now its turned around as if its consensus everywhere
David didn't say anything about consensus everywhere. He mentioned
pretty clearly that the agreement was only "in attendance", and that
this thread was a precursor for putting together a proposal to test
the waters further. That all
+1
On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
wrote:
>
> +1
>
> On Mon, Nov 25, 2019 at 11:20 AM Noble Paul wrote:
>>
>> +1
>>
>> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>> wrote:
>> >
>> > Hi,
>> > Recently, Colvin has reported
>> >
Welcome Bruno!
On Sat, Nov 23, 2019 at 9:19 PM Tomoko Uchida
wrote:
>
> Congratulations and welcome!
>
> Tomoko
>
> 2019年11月24日(日) 10:22 Otis Gospodnetić :
> >
> > Hi,
> >
> > Welcome and great work!
> >
> > Otis
> > --
> > Monitoring - Log Management - Alerting - Anomaly Detection
> > Solr &
oustant)
>>>>>
>>>>> These "Improvements" I think are better categorized as "Other":
>>>>> * LUCENE-9109: Backport some changes from master (except StackWalker) to
>>>>> improve
>>>>> TestSecurityManager (U
> Perhaps a weekly email with a list of PRs from first timers?
+1. Would be a helpful nudge for committers to pay attention to other
contributors.
On Thu, Jan 23, 2020 at 4:46 AM Jan Høydahl wrote:
>
> I added some review comments on the PR:
> https://github.com/apache/lucene-solr/pull/908 as
> It's because of the recent change to solr/.gitattributes
> (SOLR-10713) [sic - SOLR-14186] End of lines differ for adoc files. Jason --
> please
> change this one from auto to "don't touch line endings on any of other
> files", whatever the magic is.
Since the issue ended up being a bad regex
> I also think its confusing to have gitattributes at the root and then also
> under solr/
Oh, that's new. There wasn't a root gitattributes when I wrote the
solr/ one. Must have been added around the same time through the
gradle work?
Anyway, there's no technical reason afaik to keep the
+1 on Option A.
[-0] on Option B. Even though it might not be everyday, I don't think
we should put roadblocks in front of users who want to clean up after
themselves. We do occasionally see users create jira issues and then
close them themselves when they realize user error or something else
> It created an issue for me in that I spent two hours looking for a bug in the
> wrong place...
I regret that it made it harder for you to find the issue. But at the
end of the day the issue wasn't with gitattributes, it was a slip-up
in custom precommit code.
I agree with Jan - "auto"
o be totally invisible.
>
> This is mostly FYI, I happened to see the “fixcrlf” in the build files
> and thought I’d pass it along. I don’t think this should hold up the
> commit at all.
>
> Best,
> Erick
>
> > On Jan 14, 2020, at 10:18 AM, Jason Gerlowski wrote
Hi all,
Wanted to sent out a notice about a change I plan on making this week
regarding how line endings are maintained in some of our OS-specific
files (bin/solr, zkcli, etc.).
Previously it's been on committers/contributors individually to put
the correct line endings in their files. This has
Hi Martin,
If you're looking for an overview of how the code is laid out and
structured, there's not a ton there that I'm aware of. In terms of
particular features, the best resource that comes to mind would be
some of the videos of conference talks from the last several years.
I've gotten some
-1 (binding)
On Tue, May 12, 2020 at 7:31 AM Alan Woodward wrote:
>
> +1 (binding)
>
> Alan Woodward
>
> > On 12 May 2020, at 12:06, Jan Høydahl wrote:
> >
> > +1 (binding)
> >
> > Jan Høydahl
> >
> >> 12. mai 2020 kl. 09:36 skrev Dawid Weiss :
> >>
> >> Dear Lucene and Solr developers!
> >>
>
ot;Should Solr be on
> cutting-edge Lucene?"
>
> I'd be OK with a stable, robust Solr that got 1-2 major versions behind
> Lucene, but was rock-solid with a lower barrier to entry...
>
> On Wed, May 13, 2020 at 10:07 AM Jason Gerlowski
> wrote:
>>
>> Wan
> Would this not be eased to some extent if the initial committer base of both
> the projects was the same?
"Who has commit karma to a project" is a separate question from "Who
will make commits in practice". Having Lucene committers retain their
status as Solr committers only helps if they're
Wanted to add my two cents to the mix, though I'm a little late as the
vote has already progressed pretty far.
I'm against a split. From the points raised, I agree that Lucene has
much to gain. But Solr has a lot to lose.
Lucene devs would be freed from keeping Solr usage up to date. That's
a
Congrats and welcome Alessandro. Well deserved.
On Wed, Mar 18, 2020 at 2:34 PM Tomás Fernández Löbbe
wrote:
>
> Congrats and welcome Alessandro!
>
> On Wed, Mar 18, 2020 at 9:34 AM Erick Erickson
> wrote:
>>
>> Welcome Alessandro!
>>
>> On Wed, Mar 18, 2020, 10:32 Houston Putman wrote:
>>>
+1 to having some sort of vote before a big change like moving a
contrib. Also +1 to getting feedback on the user list as well; people
there might be able to give details on some of the functionality gaps
that Houston alluded to.
Personally I haven't done anything with the Analytics Component
A1, A2, D (binding)
On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless
wrote:
>
> A2, A1, C5, D (binding)
>
> Thank you to everyone for working so hard to make such cool looking possible
> future Lucene logos! And to Ryan for the challenging job of calling this
> VOTE :)
>
> Mike McCandless
>
I created a few JIRAs to spike "bin/solr" tests several years back
(SOLR-11749). I didn't have quite enough time to get it across the finish
line previously but I think it's a great idea to have tests of this sort.
At the time I was writing tests in bash - but realized that wasn't a
particularly
The Lucene PMC is pleased to announce the release of Apache Solr 8.6.3.
Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search, dynamic
clustering, database
The Lucene PMC is pleased to announce the release of Apache Lucene 8.6.3.
Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.
This
e:
> >>
> >> +1 (binding)
> >>
> >> SUCCESS! [1:00:37.423566]
> >>
> >> Tried basic indexing and search and ran the smoke tester.
> >>
> >> On Sat, Oct 3, 2020 at 6:53 PM Jason Gerlowski
> wrote:
> >>>
> >&
hitespace and Jan doesn’t
> want that for some reason and I haven’t had time to go back to it. See
> https://issues.apache.org/jira/browse/LUCENE-9434.
> On Oct 9, 2020, 11:09 AM -0500, Jason Gerlowski ,
> wrote:
>
> Small correction: I see now some pages for 8.4 and 8.6 in a di
PM Jason Gerlowski wrote:
>
> The traditional (non-docker) part of the release should now be wrapped
> up. Thanks everyone for the help and answering my questions here and
> in Slack. One final question:
>
> The final releaseWizard.py step instructs:
>
> "The Solr WIKI
s has been moved to the main project
>> : > for 9.0? Meaning, to release the 8.6.3 image there’s no change from
>> before,
>> : > right?
>> : >
>> : > I’m asking specifically about these instructions:
>> : >
>> : > https://github.com/docker-
do the upgrades for 8.7 and get that out the door rather than backport?
>
> FWIW,
> Erick
>
> > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski wrote:
> >
> > Hey all,
> >
> > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
Hi all,
I ran into a query-parsing bug recently in SOLR-14859 that caused
problems for some of my usecases. I wanted to volunteer as RM for an
8.6.3 to get a bugfix release out for users that aren't ready for some
of the bigger changes in 8.7
I was thinking of cutting the branch in a week's
ote:
>
> I was planning on a branch cut on 30th September for 8.7 — do we want to
> delay that?
>
> On Wed, 23 Sep 2020 at 19:37, Jason Gerlowski wrote:
>>
>> Hi all,
>>
>>
>>
>> I ran into a query-parsing bug recently in SOLR-14859 that ca
;> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski
>> wrote:
>>>
>>> Hi all,
>>>
>>> I ran into a query-parsing bug recently in SOLR-14859 t
I couldn't reproduce your error on running techproducts. Though
whatever is causing it locally for you sounds a bit related to
SOLR-13690 maybe?
Jason
On Wed, Sep 23, 2020 at 11:28 AM Munendra S N wrote:
>
> The wiki has steps to build solr with gradle
>
files is part of default list, so whatever replacement is there
> will need to be explicitly-named as well.
>
> Regards,
> Alex.
>
> On Fri, 25 Sep 2020 at 11:43, Jason Gerlowski wrote:
>
>
> You're left with the /filestore/ dir to put there what you want in
> standalone mo
I don't know much about the new package/file-store, but it does sound
like a good replacement for 'userfiles' (which Eric is right- is
pretty awkward to work with).
My only concerns with using the filestore would be around its
availability. Is it enabled by default (or will it be in an upcoming
ported.
>>
>> We need to transition away from the standalone mode and get rid of it
>> completely.
>>
>> On Fri, 25 Sep, 2020, 7:50 pm Jason Gerlowski, wrote:
>>>
>>> I don't know much about the new package/file-store, but it does sound
>>>
/confluence/display/SOLR/DRAFT-ReleaseNote863
[2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski wrote:
>
> The only one that was previously mentioned as a blocker was
> SOLR-14835, but from the comments on the ticket
R/versions/12348713), and it
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
> Jetty upgrade less compelling to try.
>
> Are there any other issues not currently marked for 8.6.3 we’re waiting for
> before starting the RC?
> On Sep 29, 2020, 12:04
> 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,
wrote:
>>
>> >
>>
>> > 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, a
;>
>>
>> On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma wrote:
>>>
>>> I will push the 8.7 release by a week to give Jason enough headroom to
>>>
>>>
>>> do the 8.6.3 release.
>>>
>>>
>>>
>>>
>>>
>
Please vote for release candidate 1 for Lucene/Solr 8.6.3
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
You can run the smoke tester directly with this command:
python3 -u
> Hoss’s rollups are here:
> http://fucit.org/solr-jenkins-reports/failure-report.html which show the
> rates, but not where they came from.
If I click on a particular test entry on "failure-report.html", I'm
presented with dialog with links for each failure. Clicking that link
takes me to a
> Is anyone on this list using schemaless mode in production or have you tried
> to?
Schemaless mode is one of a group of Solr features present for
convenience but not intended for production usage. It's in the same
boat as "bin/post", and SolrCell, and others. These features do cause
+1
On Fri, Aug 7, 2020 at 8:37 PM Marcus Eagan wrote:
>
> Any -1's? I just learned more about them from David Smiley earlier today and
> I recognize they are for the rare case, but I want to ensure consensus before
> I spend time on this tomorrow evening. I hadn't remembered seeing them in
>
1 - 100 of 1016 matches
Mail list logo
