Re: 8.8 Release

Thanks Tim! On Mon, 11 Jan, 2021, 11:00 pm Timothy Potter, wrote: > 15036 will be in later today, so you can plan to cut this evening US time > or tomorrow. > > Cheers, > Tim > > On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.c

Re: 8.8 Release

t ensure 8.8 includes SOLR-14923 (a bad nested >> docs performance issue) >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Wed, Jan 6, 2021 at 6:59 AM Ishan Chattopadhyaya < &

Re: Requesting a new GH repository for CrossDC modules

iginating within the umbrella of the ASF in terms of IP, copyright, or > other legal status. > > > On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> If all we need now is a place to commit a PoC for now (and something like &g

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

Yeah, my bad. I was on an older commit (commit e1e55090fb58854ba5bb0b2aa3fdd590a29a1fcc) inadvertently, even though I thought I was on the tip of the branch. On Fri, Jan 8, 2021 at 2:18 AM Timothy potter wrote: > Awesome! Thanks for fixing that quickly ... and thank you Hossman for > spotting

Re: Requesting a new GH repository for CrossDC modules

ument in favor of this approach, but I'm happy to talk more about it. >>> I just thought that based on the original email, folks were on-board >>> with the idea of this being outside of core Solr artifact/release. >>> >>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Ch

Re: 2021-01 Lucene/Solr Committer meeting

What good are these meetings if the most important issues concerning the community are off limits? On Thu, 7 Jan, 2021, 11:38 pm Anshum Gupta, wrote: > +1 :) > > Also, just a reminder for folks to put up the topics they want to discuss, > preferably with the time needed on the confluence page

Re: Requesting a new GH repository for CrossDC modules

-1 on this. Without finalizing on the shape of how the solution will look like, I don't think we should start a repository: it would be bad if we have to abandon the repository of our approach changes (say we want to keep it tightly integrated inside Solr). On Thu, 7 Jan, 2021, 11:45 pm Anshum

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

e, sharing) On Thu, Jan 7, 2021 at 11:32 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > WHen I try your exact repro line (along with the method name), I get: > BUILD FAILED > /home/ishan/code/lucene-solr/lucene/common-build.xml:1616: Not even a > single test was ex

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

WHen I try your exact repro line (along with the method name), I get: BUILD FAILED /home/ishan/code/lucene-solr/lucene/common-build.xml:1616: Not even a single test was executed (a typo in the filter pattern maybe?). When I remove the method name from the repro line, the suite executes and

Re: RFC: N-2 compatibility for file formats

Sounds great, +1 On Wed, Jan 6, 2021 at 3:10 PM Simon Willnauer wrote: > Hello all, > > Currently Lucene supports reading and writing indices that have been > created with the current or previous (N-1) version of Lucene. Lucene > refuses to open an index created by N-2 or earlier versions. > I

Re: 8.8 Release

issues someone would want me to wait on, please let me know. Thanks, Ishan On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Sure, Houston. I'll wait another week. Have a good new year and merry > Christmas! > > On Fri, 18 Dec, 202

Re: Old programmers do fade away

Thank you Erick for your guidance, mentorship and your contributions. I hope to meet you over Activate, if you're planning to come over (whenever it is organized again). I shall miss you very much. Have a great time, and I hope you secure the tomatoes and come back to Solr soon. :-) On Sat, Jan

Re: Solr Users' Slack

Forgot to mention, this effort was done in coordination with Noble and Kishore Angani, and was mostly a weekend hack. On Sat, Jan 2, 2021 at 10:25 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Hi devs, > > We support two ways of providing support: mailing list a

Solr Users' Slack

Hi devs, We support two ways of providing support: mailing list and IRC. While solr-users' list has been great for support, many users have expressed the need for more real time support. IRC, alas, has fallen out of favour these days among developers, and Slack (and others) have gained

Re: [DISCUSS] SIP-12: Incremental Backup and Restore

Thanks for taking on this effort, Jason. I'll review and suggest more next year. My initial impression is that any non core functionality should remain outside Solr core as much as possible. I hope we can leverage modularity wherever possible. On Tue, 22 Dec, 2020, 10:34 pm Jason Gerlowski,

Re: Shared Storage -- BlobDirectory, SOLR-15051

Thanks for looking at this problem, David. I have some thoughts and ideas around the same, but I'll be in a better position to comment after the holidays. Focusing on chess these days  On Tue, 22 Dec, 2020, 10:17 pm Mike Drob, wrote: > Hi David, > > Thanks for sharing. I am sure I will have

Re: 8.8 Release

e >>> > >>> > From: dev@lucene.apache.org At: 12/10/20 18:01:58 >>> > To: dev@lucene.apache.org >>> > Subject: Re: 8.8 Release >>> > >>> > +1 >>> > >>> > Joel Bernstein >>> > http://joelsolr.blogspot.com/

Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)

Let's please leave the Solr side until 8.8 is out. Some big changes are in flight and I don't want to waste time with the merges to the various branches. On Thu, 17 Dec, 2020, 8:43 pm Timothy Potter, wrote: > Sounds great Dawid! And sorely needed in this project, thanks for taking > this on.

Re: [Apache Solr] Twitter Account

n the ASF Slack. > > On Sun, Dec 6, 2020 at 9:20 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> I can volunteer. I am fairly regular with Twitter and release management. >> @Shalin >> Shekhar Mangar , if needed, please let me know. >

8.8 Release

Hi Devs, There are lots of changes accumulated and some underway. I wish to volunteer for a 8.8 release, if there are no objections. I'm planning to build the RC in three weeks, i.e. 31 December (and cut the branch about 3-4 days before that). Please let me know if someone has any concerns. Thanks

Re: [Apache Solr] Twitter Account

I can volunteer. I am fairly regular with Twitter and release management. @Shalin Shekhar Mangar , if needed, please let me know. On Sun, 6 Dec, 2020, 6:59 am Marcus Eagan, wrote: > One of the committers should pick it up, make release announcements, and > share important insights with the

Re: [Apache Solr] Twitter Account

IIRC, Shalin used to run it once upon a time. On Sat, 5 Dec, 2020, 4:10 pm Alessandro Benedetti, wrote: > Hi, > I noticed the Apache Solr twitter account not to be that active anymore. > There are not even a tweet - > release 1 to 1 matching. > Not to mention the countless interesting blog

Re: Solr: Separate CHANGES.txt for Docker, SolrJ, Contribs, ...

I think whatever we don't ship in the main tarball today should stay separate. Going forward, when we stop shoving the extra modules (contribs) into the main distro, we can separate out their changelogs. However, I feel SolrJ changes should stay with Solr changes since it is also used heavily in

Re: Welcome Julie Tibshirani as Lucene/Solr committer

Welcome Julie! On Thu, 19 Nov, 2020, 12:10 am Erick Erickson, wrote: > Welcome Julie! > > > On Nov 18, 2020, at 1:21 PM, Alexandre Rafalovitch > wrote: > > > > Juliet from the house of Elasticsearch meets a interesting, > relevancy-aware committer from the house of Solr. > > > > Such a

Re: Solr 8.x and contribs requiring Java 11

> > Le ven. 30 oct. 2020 à 18:33, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> a écrit : > >> +1 to removing it (in 8.7 with a respin, if needed). If we can't support >> it, there's no need to keep it. If someone wants, they can assume ownership >> of a t

Re: Solr 8.x and contribs requiring Java 11

+1 to removing it (in 8.7 with a respin, if needed). If we can't support it, there's no need to keep it. If someone wants, they can assume ownership of a third party package. +1 to removing all non essential code and trimming down the Solr distribution. There's no good reason for Solr, which is in

Re: 8.6.3 Release

I guess some convention due to MoinMoin? On Thu, 22 Oct, 2020, 7:25 pm Jason Gerlowski, wrote: > On the topic - is there a particular reason behind the convention of > having the page titles be named without spaces or periods? As is they > look more like Java classnames than page titles. e.g.

Re: 8.7 Release

gt;>> Thanks, > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Cassandra > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>&g

Re: [jira] [Commented] (SOLR-14923) Indexing performance is unacceptable when child documents are involved

This is a classic example of why *every change to default code paths* for core components must accompany performance benchmarks. On Tue, 20 Oct, 2020, 1:35 pm Thomas Wöckinger, wrote: > Did you have time to look at this? > > On Tue, Oct 13, 2020 at 2:43 PM David Smiley (Jira) > wrote: > >> >>

Re: Please set: git config --global pull.rebase true

I don't think it is disabled for Lucene-solr, ab. I can do forced pushes on jira branches, but not sure about branch-8x or master. +100 agree with avoiding forced pushes. I think I was on your team in a previous job once when forced pushes caused us so much trouble. I fully support disabling it

Re: Removal of Apache HttpComponents/HttpClient for 9.0?

Maybe we need them for kerberos? I'm totally fine getting rid of kerberos support from Solr core some day, but it might not be very easy to refactor it into a package. On Sat, 10 Oct, 2020, 10:26 pm David Smiley, wrote: > I think that historically, we are good at adding code but not good at >

Re: Index documents in async way

Can there be a situation where the index writer fails after the document was added to tlog and a success is sent to the user? I think we want to avoid such a situation, isn't it? On Thu, 8 Oct, 2020, 8:25 pm Cao Mạnh Đạt, wrote: > > Can you explain a little more on how this would impact

Re: Solr Alpha (EA) release of Reference Branch

hat's fine we can continue in > following releases. > > My 2 cents... > Ilan > > Le mar. 6 oct. 2020 à 09:56, Noble Paul a écrit : > >> Yes, A docker image will definitely help. I wasn't trying to downplay that >> >> On Tue, Oct 6, 2020 at 6:55 PM Ishan Chatto

Re: Solr Alpha (EA) release of Reference Branch

ter I disagree, Noble. Having a docker image us going to be useful to some clients, with complex usecases. Great point, David! On Tue, 6 Oct, 2020, 1:09 pm Ishan Chattopadhyaya, < ichattopadhy...@gmail.com> wrote: > As I said, I'm *personally* not confident in putting such a b

Re: Solr Alpha (EA) release of Reference Branch

As I said, I'm *personally* not confident in putting such a big changeset into master that wasn't vetted in a real user environment widely. I have, in the past, done enough bad things to Solr (directly or indirectly), and I don't want to repeat the same. Also, I'll be very uncomfortable if someone

Re: Solr Alpha (EA) release of Reference Branch

-evaluated at the time of the release to see if we need to delay it, it still makes sense to go with the release, or any major shifts in direction is needed. Thanks everyone for your suggestions, thoughts and concerns. On Mon, 5 Oct, 2020, 6:43 pm Ishan Chattopadhyaya, < ichattopadhy...@gmail.com>

Re: Solr Alpha (EA) release of Reference Branch

nst it. > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > From: Ishan Chattopadhyaya > > Sent: Sunday, October 4, 2020 6:32 AM > > To: Uwe

Re: Solr Alpha (EA) release of Reference Branch

u have a sense into > how that would end up playing out? Could it be brought in chunks or would > it have to be wholesale ? > > > > Also do you know what features in the reference branch have been removed > because they were unstable ? Finding out the features/bug-fixes in master

Re: Solr Alpha (EA) release of Reference Branch

Erick, I'll answer your questions shortly. On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, < ichattopadhy...@gmail.com> wrote: > Agree, Noble. Let's not worry about the naming too much. We can discuss > that later as well, or in a separate thread. > > On Sun, 4 Oct, 2020, 1

Re: Solr Alpha (EA) release of Reference Branch

> > Is the branch ready for Jenkins testing? > > > > If yes and "gradlew check" works, I really would like to set it up. > > > > Uwe > > > > Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>:

Re: Solr Alpha (EA) release of Reference Branch

heck" works, I really would like to set it up. > > Uwe > > Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: >> >> Hi Devs, >> >> As you might be aware, the reference_impl branch has a lot of >> imp

Solr Alpha (EA) release of Reference Branch

Hi Devs, As you might be aware, the reference_impl branch has a lot of improvements that we want to see in Solr master. However, it is currently a large deviation from master and hence the stability and reliability (though improved in certain aspects) remains to be tested in real production

Re: What is "Solr core"?

Yes, solr-core usually means /solr/core module in the repository. It also refers to the generated artifact solr-core-.jar. > Or is it a dependency graph where "core" > depends on nothing outside of core, but anything outside of core can > depend on core? solr-core depends on solrj module, but

Backward compatability handling across major versions

Hi Devs, As per earlier discussions, we want to do a better job of handling major version upgrades, possibly support rolling upgrades wherever possible. This implies that we don't break backward compatibility without a strong reason and adequate discussion around it. Recently, there was a PR that

Re: restlet dependencies

@Endpoint annotations. It is available for V2 APIs today (and I think it should be fine to use for anything we build now onwards, including managed resources V2). It is possible to make it work with V1, but that will require some work. On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya < ichattopadhy.

Re: restlet dependencies

ll, I believe we should have a mechanism to upload a single file > to > >>>>>> a configset. > >>>>>> > >>>>>> > A single file configset upload would require the user to reload > the collection, so i

Re: restlet dependencies

additional edits to be done (e.g. > query-elevation or other word lists). > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>

Re: restlet dependencies

ee. Whatever alternative we build should address these, before we consider removing managed resources. On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > The managed resources is the only reasonable way to upload synonyms on the > fly for us

Re: restlet dependencies

lt in more or less persistent servers and there is > no issue. > > What's the problem? > > Uwe > > Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: >> >> Can we discuss this with ASF and get an exception for this?

Re: restlet dependencies

Can we discuss this with ASF and get an exception for this? On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, wrote: > We can't have or redistribute binaries in ASL sources - that's my > understanding. > > Dawid > > On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya > wrote

Re: restlet dependencies

bbe > @Ishan Chattopadhyaya > Let's support the single file upload feature. Let's automatically make > that configset "untrusted" if any file is uploaded over REST. Those > "untrusted" features are not really important for normal users > > On Wed, Sep 30, 2020 at 3

Re: restlet dependencies

Can we pull in the jar inside our codebase? On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, wrote: > > We can upgrade if it doesn't break anything... which I can't guarantee. ;) > > Dawid > >>

Re: Filestore, subsume userfiles requirement

Standalone isn't supported. 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 > like a good replacement for 'userfiles' (which Eric is

Re: Filestore, subsume userfiles requirement

+1 We can even obsolete the blob store on favour of the package store (once it is renamed to file store). We built the package store as a general purpose distributed file store. Since we were running fast with the package manager, we didn't advertise it for all of its capabilities as a generic

Re: restlet dependencies

SOLR-5287 has some discussion. The changes were backed out due to security reasons. Anyway, Eric, Tomas & David, let us not hijack this thread on restlet and discuss something totally unrelated. On Fri, 25 Sep, 2020, 9:20 am Ishan Chattopadhyaya, < ichattopadhy...@gmail.com> wrote: &

Re: restlet dependencies

How is it less secure or harder > to secure than, say, a configSet upload (internally multiple files)? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Sep 24, 2020 at 1:53 PM Ishan Chattopadhyaya < >

Re: restlet dependencies

esources support from 9 >>>> instead of porting the Restlet code but I don't know if 9 is too soon from >>>> a deprecation stand point? >>>> >>>> Tim >>>> >>>> >>>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul >&g

Re: 8.6.3 Release

The release process is not conducive to simultaneous releases. We need to space them out. On Thu, Sep 24, 2020 at 12:01 AM Atri Sharma wrote: > I am not sure if two close releases are a good idea — would they not lead > to potential confusion amongst users? > > In any case, I will defer to the

Re: 8.6.3 Release

+1 On Wed, 23 Sep, 2020, 8:23 pm Andrzej Białecki, wrote: > I’d like to fix & backport SOLR-14850 & SOLR-14835. > > > On 23 Sep 2020, at 16:06, Jason Gerlowski wrote: > > > > Hi all, > > > > I ran into a query-parsing bug recently in SOLR-14859 that caused > > problems for some of my usecases.

Re: restlet dependencies

spot.com/ > >> > > >> > > >> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh < > ep...@opensourceconnections.com> wrote: > >> >> > >> >> Do we have a community blessed alternative to restlet already? > >> >> > >> >> On

Re: restlet dependencies

;>> To: dev@lucene.apache.org >>> Subject: Re: restlet dependencies >>> >>> I don't think it is, sadly. >>> https://repo1.maven.org/maven2/org/restlet >>> >>> The link you provided (mvnrepository) aggregates from several maven >>>

Re: Github PR Actions

> 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

Re: restlet dependencies

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

Re: restlet dependencies

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

Re: Github PR Actions

> It would be great to run all the tests every time, but clearly that is too expensive. The reference_impl branch requires around 30 seconds to run all solr-core tests. That's where we should all put our collective efforts. Also, I have reservations against docker based tests blocking PRs. If I

Re: Placement plugin PR commit - soon

+1. Thanks for the heads up! This is a practice we all should adopt. On Tue, 15 Sep, 2020, 4:06 am Ilan Ginzburg, wrote: > Advance notice: > > I plan to commit to master/9.0 coming Wednesday September 16th the "Placement > plugin" PR

Re: Notification of analysis on publicly available project data

Is there any PMC action or support/cooperation needed here from our part? On Thu, 10 Sep, 2020, 10:19 pm Griselda Cuevas, wrote: > Dear PMC, > > > I’m contacting you because your project has been selected by the ASF D > committee which is leading a research project to evaluate and understand >

Re: [jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API

I think I misunderstood the intent of this jira. This is not a user facing api, as I originally thought, but rather a refactoring of internal code with respect to how various components access configuration pieces of Solr. If that is the correct understanding, please go ahead as soon as possible

Re: Tests that use bin/solr?

+1 This should be used to write tests for rolling upgrades across different versions. On Mon, 7 Sep, 2020, 12:30 pm Dawid Weiss, wrote: > Just a note - such integration tests should depend on (and consume) > the output of solr/packaging (a ZIP file with fully assembled > package). Then you're

Re: Solr configuration options

On Fri, 4 Sep, 2020, 12:05 am Erick Erickson, wrote: > > > I wish everyone would just use Solr the way I think about it ;) > https://twitter.com/ichattopadhyaya/status/1210868171814473728 > > On Sep 3, 2020, at 2:11 PM, Tomás Fernández Löbbe > wrote: > > > > I can see that some of these

Re: Solr configuration options

Hi Tomas, This type of a problem can be solved using alternate strategies. Here's how you can do so: register the updated version of the plugin in /healthcheck2 (while simultaneously the older version continues to work at /healthcheck). Make sure it works. Once it does, update the /healthcheck

Re: Migrate Solr helm chart into apache/lucene-solr repo

Hi Lee, Atri, I'd like to volunteer to maintaining Solr Helm charts in a public GitHub repository outside of Apache, unless we want to do so as part of Lucene-Solr or elsewhere in Apache. Regards, Ishan On Thu, 3 Sep, 2020, 8:16 pm Atri Sharma, wrote: > The CouchDB example is a good one -- it

Re: Analytics Module; maybe should be 3rd party?

+1, please open a jira and I'll take care of it. Fyi, Marcus is helping me with migrating contrib modules to first party package, and this was on our radar. I am totally occupied in other things lately and hence slowed down on that effort. Will pick up pace end of this week. On Tue, 1 Sep, 2020,

Re: SIP-10: Solr 9 examples: Can we use Ref Guide as a dogfood example?

I love the idea of making the ref guide itself as an example dataset. That way, we won't need to ship anything separately. Python's beautiful soup can extract text from the html pages. I'm sure there maybe such things in Java too (can Tika do this?). On Mon, 31 Aug, 2020, 11:18 pm Alexandre

Re: Plan for Velocity

https://issues.apache.org/jira/browse/SOLR-14065 Description contains the Erik's repository. On Mon, Aug 31, 2020 at 2:38 AM Varun Thacker wrote: > SOLR-14065 deprecated Velocity in 8.4 . Is the plan to remove it for 9.0 ? > > If this has already been discussed please feel free to point me to

Re: Plan for Velocity

Yes, plan to remove it in 9.0. On Mon, Aug 31, 2020 at 4:13 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > https://issues.apache.org/jira/browse/SOLR-14065 > Description contains the Erik's repository. > > On Mon, Aug 31, 2020 at 2:38 AM Varun Thacker wrot

Re: RoadMap?

; later (even on Lucene 9.x). Looks like we have tons of major goodies lined > up - it won’t all need to land in 9.0. Guess that’s what the Roadmap page > is there for. So as David says, let’s start placing the removal JIRAs into > the roadmap page and see if we’re still on the same

Re: RoadMap?

Ps. I don't know the degree of 'broken' of this specific feature. So, > I am mostly talking practical principles here. > > On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya > wrote: > > > > > I find it highly depressing that we can't, *in a major release*, > manage to get r

Re: RoadMap?

Considering, Planned, Rejected > >>>> > >>>> Workflow like this: > >>>> Proposed ---(no objection 1 wk) --> Planned > >>>> Proposed ---(discussion)--> Considering > >>>> Considering (agreement) -

Re: Benchmark for Apache Lucene Library

https://home.apache.org/~mikemccand/lucenebench/ On Fri, 28 Aug, 2020, 1:12 am Performance Enggring, < performance.enggr...@gmail.com> wrote: > Hello Lucene Experts, > > Hope everyone is doing well! > > I am looking for an Apache Lucene benchmark tool, which covers all key > aspects of a

Re: SIP-10 Improve Getting Started experience

+1 to this effort and thanks for stepping up. I think we shouldn't unnecessarily constrain ourselves only with what works today: if there's something that is clearly better, let's fix/build it so that we have a pleasant user experience. Just my two cents. Case in point: data driven schemaless

Re: Lucene/Solr 8.6.2 bugfix release

+1 On Tue, 25 Aug, 2020, 11:19 am Ignacio Vera, wrote: > Hi, > > I propose a 8.6.2 bugfix release and I volunteer as RM. The motivation for > this release is LUCENE-9478 where Simon addressed a serious memory leak in > DWPTDeleteQueue. > > If there are no objections I am planning to build the

Re: Lucene/Solr 8.6.2 bugfix release

Thanks Simon and Ignacio! On Tue, 25 Aug, 2020, 11:21 am Simon Willnauer, wrote: > +1 thank you! I was about to write the same email. Lets sync on the RM > I can certainly help... I need to go and find my code signing key > first :) > > simon > > On Tue, Aug 25, 2020 at 7:49 AM Ignacio Vera

Re: 8.7 Release

ked JIRA, > and while I see a number of 9.0 blockers, I'm not counting many 8.7 > blockers? > > On Thu, Aug 20, 2020 at 11:13 AM Noble Paul wrote: > >> There are a lot of blockers for 8.7. It's good to plan in advance >> >> On Thu, Aug 20, 2020 at 7:11 PM Ishan Chattop

Welcome Atri Sharma to the PMC

I am pleased to announce that Atri Sharma has accepted the PMC's invitation to join. Congratulations and welcome, Atri!

Re: 8.7 Release

ood to plan in advance > > On Thu, Aug 20, 2020 at 7:11 PM Ishan Chattopadhyaya > wrote: > > > > Hi devs, > > A lot of changes are now in 8.7 or in-flight. I'd like to volunteer for > a 8.7 release in around a month from now (cutting the release branch around > 20 Sep

8.7 Release

Hi devs, A lot of changes are now in 8.7 or in-flight. I'd like to volunteer for a 8.7 release in around a month from now (cutting the *release branch* around *20 September*) and RC shortly after. I feel this timeline will give all of us ample time to wrap up the release blockers, other changes

Re: Performance testing is necessary now

030=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17170030 I shall try other ways next time to alert you as JIRA comments do sometimes get lost in the noise. On Wed, Aug 12, 2020 at 6:44 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Sure Andrzej, I *sincerely* apologize. I felt Houston and

Re: RoadMap?

r release) >>> Planned (difficulty found) ---> Considering >>> >>> Anything in "Considering" should have an active dev list thread, and if >>> it didn't happen on the list it didn't happen :). Any of that (or >>> differences of opinion during Cons

Re: Performance testing is necessary now

help whenever you need. I shall focus on making automated performance testing a higher priority. On Wed, Aug 12, 2020 at 6:26 PM Andrzej Białecki wrote: > > On 12 Aug 2020, at 07:06, Ishan Chattopadhyaya > wrote: > > > > Whatever we do or not do is imperfect. I hope some &qu

Re: Performance testing is necessary now

, that we all do our best to preserve (and only improve) the performance characteristics of Solr for the sake of our users. Thanks to everyone for your inputs. Regards, Ishan On Wed, Aug 12, 2020 at 10:36 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > > Maybe if we h

Re: Remove/Replace Nashorn, Remove Eval

+1 to removing it. Does the build pass if we remove that line? On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan wrote: > Not trying to spam the list, just looking to get feedback about the goings > on in the project and on some of my items before I share my Google Doc, > which is damning, even of

Re: Performance testing is necessary now

ion, please suggest. > If those > things are blocked, we'll be trading the opportunity cost of the change for the performance > risk. Each issue is different -- has its own risk-reward trade-off. Just keep this in mind, Ishan. I totally understand. On Wed, Aug 12, 2020 at 10:18 AM Ishan C

Re: Performance testing is necessary now

10:03 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > > I was going to use the data set the Mike uses for the lucene nightly > benchmarks > I've gone with the same in the suite to begin with: > https://github.com/TheSearchStack/solr-bench/blob/master/sma

Re: Performance testing is necessary now

lso capable of using .jsonl files, and I'm building another dataset (based on Hacker News articles) for that at the moment. On Wed, Aug 12, 2020 at 10:00 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Here's the local mode example: > https://github.com/TheSearchStack/solr-be

Re: Performance testing is necessary now

e repo. > > On Tue, Aug 11, 2020 at 4:30 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> Local mode uses the installed JDK. GCP mode can pick up a JDK url as >> configured. It is just a configuration, one among many, that can be changed >> as p

Re: Performance testing is necessary now

try to download a jdk from >> some university website? That seems overly restrictive to me, why can't we >> use the already installed JDK? >> >> Is the benchmark suite designed for master? Or for branch_8x? >> >> Mike >> >> On Tue, Aug 11, 2020 at 9:0

Re: Performance testing is necessary now

art of our dev processes, just like Jenkins based testing is today. On Wed, 12 Aug, 2020, 3:00 am Ishan Chattopadhyaya, < ichattopadhy...@gmail.com> wrote: > Local mode uses the installed JDK. GCP mode can pick up a JDK url as > configured. It is just a configuration, one among

Re: Performance testing is necessary now

mark suite designed for master? Or for branch_8x? > > Mike > > On Tue, Aug 11, 2020 at 9:04 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> Hi Everyone! >>From now on, I intend to request/nag/demand/veto code changes, which >> affect def

Re: Naming of non-SolrCloud clusters in the Ref Guide

yone. > > I’ve tried to put real mental work into thinking about a good name, and > have tried to compromise based on feedback. At this point, though, unless > someone else comes up with something I’m likely done here. We’ll just > “leave it” all as it is now. > > Cassandra > On A

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