Some 9.0 proposals of mine

The following changes are on my mind for 9.0, and some others. I will do many; others I'm a reviewer for a contributor. I think these are best done on a major release, but this isn't to say each is "important". Jan (as RM), please let me know what you think. I suppose I need your approval? Obse

Re: Quarterly Committer Meetings

I created a wiki page for the meeting: https://cwiki.apache.org/confluence/display/SOLR/2022-01-20+Meeting+notes I propose that we try and keep this meeting to one topic: 9.0, which is big because it's any changes to discuss that may/may-not make 9.0. The meeting release cadence will increase so

Re: Quarterly Committer Meetings

+1 I am not around too much these days but I'd love to see everyone and listen in on the discussions. On Tue, Jan 11, 2022 at 8:07 AM David Smiley wrote: > Hello everyone, > > I would like to propose that we have Solr committer online meetings, as we > did sporadically previously, but hencefort

Re: Quarterly Committer Meetings

+1 Do we have a place to gather agenda items ahead of time? On Thu, Jan 13, 2022 at 8:12 AM Gus Heck wrote: > +1, please send a link to me too. > > On Thu, Jan 13, 2022 at 3:52 AM Bruno Roustant > wrote: > >> +1 >> I'll try to make it, probably with some lateness. >> >> Bruno >> >> Le jeu. 13

Re: Modularizing Solr with new contrib packages

+1 to your phasing. > Another minor improvement for users is if we pre-add $SOLR_TIP/lib to the > classloader I'll create a JIRA :) SOLR-HOME/lib is already supported -- https://nightlies.apache.org/solr/draft-guides/solr-reference-guide-main/libs.html This is what I recommend people use in ge

Re: Propose changing the "dist" layout

> > So would make sense to move configsets out to $SOLR_TIP/configsets and >> have the default location of SOLR_HOME be not "./solr" but $TEMP/solr or >> something? >> > > Regardless of the rest of this discussion I think this would be a big win. > Currently it's a pain (especially for new users/co

Re: Propose changing the "dist" layout

> > So would make sense to move configsets out to $SOLR_TIP/configsets and > have the default location of SOLR_HOME be not "./solr" but $TEMP/solr or > something? > Regardless of the rest of this discussion I think this would be a big win. Currently it's a pain (especially for new users/contributo

Re: Modularizing Solr with new contrib packages

> > It could very well be worth shipping two docker images in the meantime. > Or maybe a zip of each module could be a separate artifact that is > published? I'm not sure what freedoms we have to do this in the ASF. > I think for 9.0 we could realistically shoot for 2 binary releases and 2 docker

Re: Prometheus Exporter; new location?

Thanks for listing these out David. I think for the sake of 9.0, I choose (A). For 10.0 and beyond, I think I would prefer (B). You are right that if it is in it's own repo (C) it will not get much looks/releases. Which could be fine, but I think it's nice that it has to release with every Solr ve

Re: Quarterly Committer Meetings

+1, please send a link to me too. On Thu, Jan 13, 2022 at 3:52 AM Bruno Roustant wrote: > +1 > I'll try to make it, probably with some lateness. > > Bruno > > Le jeu. 13 janv. 2022 à 03:34, Shawn Heisey a > écrit : > >> On 1/12/2022 3:46 AM, Alessandro Benedetti wrote: >> > +1, the time works f

Re: Propose changing the "dist" layout

See https://issues.apache.org/jira/browse/SOLR-15917 for renaming of "contribs" discussion. Wrt server/ folder that is in reality the jetty distribution with an added "solr" folder for historic reasons. Yea, it is confusing. The "solr" folder will become $SOLR_HOME if you start Solr without an

Re: Modularizing Solr with new contrib packages

Another minor improvement for users is if we pre-add $SOLR_TIP/lib to the classloader, similar to what we have with $SOLR_HOME/lib today. The disadvantage of $SOLR_HOME/lib is that it can be anywhere, perhaps on a Docker volume or a different disk, so you cannot e.g make a Dockerfile like FROM

Re: Modularizing Solr with new contrib packages

There is not a lack of vision for future local and remote package repositories, but the story is that package mgmt development has stalled, and is out of reach for 1st party pkgs in the 9.0.0 timeframe. So we have to think progress over perfection - once again Phase 1. (9.0): Modularize Solr by

Re: [DISCUSS] Mark Rate Limiting as Experimental for Solr 9.0

+1 as well, I only discovered it because I saw the fixes that Mike made! > On Jan 13, 2022, at 3:43 AM, Bruno Roustant wrote: > > +1 > It will allow folks to try it (me included?) > > Bruno > > Le mer. 12 janv. 2022 à 17:00, Mike Drob > a écrit : > Howdy folks, > > A

Re: Prometheus Exporter; new location?

It's kind of a free-rider for sure, and a convenient one :) Ideally I'd like (C), but pragmatically for 9.0 I vote for (A) unless someone steps up with lots of energy :) If we did C, there'd be a separate release artifact in CDN alongside solr-operator. The Docke

Re: Propose changing the "dist" layout

+1 renaming for contribs -> plugins +1 for re-structuring dist I also would like to raise some concern over the 'server' directory structure: README.txt lib resources solr-webapp contexts logs scripts start.jar etc modules solr I have been using it for years, and still, sometimes I get lost, s

Re: Quarterly Committer Meetings

+1 I'll try to make it, probably with some lateness. Bruno Le jeu. 13 janv. 2022 à 03:34, Shawn Heisey a écrit : > On 1/12/2022 3:46 AM, Alessandro Benedetti wrote: > > +1, the time works for me and I am in! > > > > Do we have a calendar event already? > > Looking forward to seeing a Google Mee

Re: [DISCUSS] Mark Rate Limiting as Experimental for Solr 9.0

+1 It will allow folks to try it (me included?) Bruno Le mer. 12 janv. 2022 à 17:00, Mike Drob a écrit : > Howdy folks, > > After finding two quick bugs in the rate limiting code[1][2], I suspect > that this feature has largely gone untested in our code up until now. I > also looked at TestRequ