Re: [ANNOUNCE] Apache Solr TLP - Mailing lists created
Anyone who struggles to get themselves unsubscribed is welcome to contact me. I have the ability to remove people - I just need to receive an email from the address that is subscribed. Malcolm / Upayavira On Sat, 6 Mar 2021, at 12:54 AM, Anshum Gupta wrote: > As a lot of you reached out to me about wanting to unsubscribe and I'm unable > to manually process this for each of you, > > I recommend folks who want to unsubscribe from a mailing list to do so by > just sending an email to -unsubscr...@lucene.apache.org or > -unsubscr...@solr.apache.org, based on what the address for the > mailing list is e.g. If you want to unsubscribe from general@l.a.o, you can > do so by sending an email to general-unsubscribe@l.a.o. > > > > On Fri, Mar 5, 2021 at 3:33 PM Anshum Gupta wrote: >> >> Hi everyone, >> >> I'd like to inform you that new mailing lists have been created as part of >> the bootstrapping of the newly created Apache Solr TLP. Below are all the >> lists and their corresponding subscription request addresses that will be >> used for Solr going forward: >> >> 1. *Solr Dev* - d...@solr.apache.org [dev-subscr...@solr.apache.org] >> 2. *Builds* - bui...@solr.apache.org [builds-subscr...@solr.apache.org] >> 3. *Commits* - comm...@solr.apache.org [commits-subscr...@solr.apache.org] >> 4. *Issues* - iss...@solr.apache.org [issues-subscr...@solr.apache.org] >> >> The *Solr user mailing list has been migrated* from >> solr-u...@lucene.apache.org to *us...@solr.apache.org*. As part of this >> migration, all people who were subscribed to the old list continue to be >> subscribed to the new one. Any email sent to the old list going forward will >> automatically be redirected to the new address with an updated reply-to >> address i.e. emails for existing threads will be gracefully migrated. Please >> fix any mail filters you may have for this list. >> >> For more information please see - >> https://solr.apache.org/community.html#mailing-lists-chat >> >> Feel free to reach out to the Solr PMC in case of any questions or issues. >> >> -Anshum >> On behalf of the Apache Solr PMC >> > > > -- > Anshum Gupta
Re: Renaming SolrCloud
Solr can run Zookeeper embedded. Just make the 'standalone' version run a Zookeeper, then you can deprecate the standalone mode entirely. Also, given that installing ZooKeeper is a pain, and that Solr has the embedded ability to run ZooKeeper, it always seemed a good idea to me to have the option to run ZK from within the Solr codebase, e.g: solr zookeeper start --various=options Would start a Zookeeper instance, and make one less thing to go download. Upayavira On Mon, 14 Oct 2019, at 5:40 PM, Doug Turnbull wrote: > I agree very much on normalizing to one mode of running Solr > > So long as the 'cluster mode' hello world is easier than having to think a > lot about zookeeper and other hard things. One reason people use standalone > mode because it's as simple as "Point '/bin/solr' at config directory and > go". If there's just cluster mode, it all should be dead simple to help > newbies play around with Solr without thinking that hard > > -Douc > > On Mon, Oct 14, 2019 at 12:36 PM Houston Putman > wrote: >> Jan, >> >> I agree strongly with your last point. And in case you haven't seen it >> before, there is a solr k8s operator, with a growing community, under >> development at https://github.com/bloomberg/solr-operator. >> >> I agree that taking control of the solr docker images could be a good idea. >> That way, it could have larger involvement from the community and grow more >> organically with changes in Solr itself. >> >> - Houston >> >> On Tue, Oct 8, 2019 at 8:25 PM Noble Paul wrote: >>> Why even "cluster mode" or "cloud mode"? >>> >>> Solr, by default , should use the cluster mode. So in all our >>> documentation, we should use just "Solr" and it should refer to a >>> "cluster mode of Solr" >>> >>> Wherever we don't have a "cluster mode" should be explicitly qualified >>> as "standalone Solr" >>> >>> On Wed, Oct 2, 2019 at 1:24 PM David Smiley >>> wrote: >>> > >>> > I hear you and sympathize but "SolrCloud" has been used long enough that >>> I doubt the trouble is worth it. I guess that makes me "+0". That said, I >>> think it wouldn't hurt to formalize "standalone mode" as-such and perhaps >>> say more explicitly that SolrCloud == "cluster mode" even if we don't >>> eliminate SolrCloud terminology. >>> > >>> > And as SolrCloud ... errr... "cluster mode" I mean, gains in usage >>> relative to "standalone mode", perhaps we can reference SolrCloud less >>> often and sorta assume that and instead make exceptions in documentation to >>> standalone mode specifics where we call that out as such. It's a loose >>> idea; I'm don't have an example in mind. >>> > >>> > Similar to the above notion, maybe "CloudSolrClient" could be more >>> invisible without renaming it. Imagine SolrClient.createFromZooKeeper() >>> etc. static methods that instantiate CloudSolrClient by default. Just a >>> thought. >>> > >>> > ~ David Smiley >>> > Apache Lucene/Solr Search Developer >>> > http://www.linkedin.com/in/davidwsmiley >>> > >>> > >>> > On Mon, Sep 30, 2019 at 11:19 AM Shawn Heisey >>> wrote: >>> >> >>> >> On 9/30/2019 6:59 AM, Ishan Chattopadhyaya wrote: >>> >> > I propose that we rename SolrCloud mode to "cluster mode" such that >>> >> > there shall be "Apache Solr", running in either "standalone mode" or >>> >> > "cluster mode". We can effect this renaming 9.0 onwards, if we have >>> >> > consensus. >>> >> > >>> >> > I am open to any other proposal as well, so long as we drop the >>> "cloud" >>> >> > in the name. >>> >> >>> >> I see your point, but I think that "cloud" is so entrenched in the >>> >> overall consciousness of the software that changing it will not be easy. >>> >> >>> >> Maybe it might be something we could accomplish slowly, over the rest of >>> >> 8.0's lifetime and the entire 9.0 lifetime. Begin changing the >>> >> terminology we use in communication, start shifting documentation and >>> >> code, with a hard cutover in a later major version, perhaps 10.0 or >>> 11.0. >>> >> >>> >> The level of effort involved would be considerable, whether it happens >>> >> quickly or slowly. It might be the kind of thing we just don't want to >>> >> try and do. >>> >> >>> >> I'm not opposed to the idea, and I might even be able to help, but it's >>> >> going to need a lot of buy-in from those of us who work on Solr. >>> >> >>> >> Thanks, >>> >> Shawn >>> >> >>> >> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >>> >>> >>> -- >>> - >>> Noble Paul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> > > > -- > *Doug Turnbull **| CTO* |
Re: Poll: Merge jira/http2 to master branch
Uwe - there is already a release newer than the commit On Tue, 27 Nov 2018, at 8:03 AM, Uwe Schindler wrote: > Ah I figured out, there is an issue open already: > https://github.com/google/conscrypt/issues/560 > > Seems to be closed, so we have to wait for a new release, right? > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Uwe Schindler > > Sent: Tuesday, November 27, 2018 8:48 AM > > To: dev@lucene.apache.org > > Subject: RE: Poll: Merge jira/http2 to master branch > > > > It seems to work with Java 9/10/11, but with Java 8 almost all Solr tests > > fail. > > Reason is a mising JAR library: conscrypt.jar (which seems to be used by > > Jetty > > to support some HTTP/2 requires stuff not included in the JDK). > > > > We should at least disable HTTP/2 in Java 8 or add this library (seems to > > contain native code): https://github.com/google/conscrypt#uber-jar > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > -Original Message- > > > From: Uwe Schindler > > > Sent: Tuesday, November 27, 2018 12:38 AM > > > To: dev@lucene.apache.org > > > Subject: RE: Poll: Merge jira/http2 to master branch > > > > > > OK, > > > > > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos, Solaris). On > > > ASF Jenkins I created the standard "tests" job for now, others can be > > > added > > > later. They are called "http2" at the place of the version (instead of > > > "7.x", > > > "7.6", "master"). > > > > > > Let's see how it behaves, > > > Uwe > > > > > > - > > > Uwe Schindler > > > Achterdiek 19, D-28357 Bremen > > > http://www.thetaphi.de > > > eMail: u...@thetaphi.de > > > > > > > -Original Message- > > > > From: Uwe Schindler > > > > Sent: Tuesday, November 27, 2018 12:22 AM > > > > To: dev@lucene.apache.org > > > > Subject: RE: Poll: Merge jira/http2 to master branch > > > > > > > > Ah sorry, I did not see the ping. Where did you try to contact me? > > > > > > > > Uwe > > > > > > > > - > > > > Uwe Schindler > > > > Achterdiek 19, D-28357 Bremen > > > > http://www.thetaphi.de > > > > eMail: u...@thetaphi.de > > > > > > > > > -Original Message- > > > > > From: Chris Hostetter > > > > > Sent: Monday, November 26, 2018 10:59 PM > > > > > To: dev@lucene.apache.org > > > > > Subject: RE: Poll: Merge jira/http2 to master branch > > > > > > > > > > > > > > > : 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 :) > > > > > > > > > > And yes: if my experimentation is correct, we should see a much lower > > > rate > > > > > of failures from your box when testing Dat's http2 branch with java>9 > > > > > vs > > > > > what we see w/master & 7x > > > > > > > > > > : > : 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 the most, and AFAICT those problems are fixed on the > > jira/http2 > > > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988) > > > > > > > > > > > > > > > -Hoss > > > > > http://www.lucidworks.com/ > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
