We do not have to provide all features. Whatever feature we provide, it should be reasonably bug free, performant and stable.
There is no point in carrying around a lot of baggage if we are barely able to carry it. There are a lot of "dark areas" in Solr which nobody pays attention to. Those features should be removed altogether. If there are committers who wish to actively support it , we can maintain them in packages. If, not we should euthanize them gracefully On Fri, Aug 28, 2020 at 5:43 PM Ishan Chattopadhyaya <[email protected]> wrote: > > > The consensus from yesterday seems to be that stuff with a released > > replacement can/should be removed in 9.0, but for CDCR and SolrCell, where > > the proejct still wants to provide a better alternative, they can remain > > deprecated 9.x. > > I disagree that "project still wants to provide a better alternative", at > least for CDCR. There is no movement in that direction. Part of the reason > people take supporting these features seriously is the threat or > deprecation/removal (e.g. HDFS, Velocity, DIH, Autoscaling etc.). The moment > we deprecate/remove SolrCell, we will see the better alternatives emerge. And > both of them must be removed, even if better alternatives do not emerge. They > both must be removed in 9.0. Let us not carry the burden into another major > release. > > On Fri, Aug 28, 2020 at 12:49 PM Jan Høydahl <[email protected]> wrote: >> >> Hi, >> >> I phrased that sentence in the roadmap Wiki, but I think the wording is more >> conservative than need-be. The intent was really to avoid a situation where >> 9.0 goes out the door «tomorrow» without a replacement for a popular feature >> that the community really wants. I attempted a re-phrase of that sentence >> after the meeting yesterday, but did not immediately find a better wording. >> >> Personally I think a deprecation in 8.6 can be removed in 9.0 (there’ll be >> several months and 2’ish releases in between) if it has a well known, >> released replacement/package. And let’s link to those packages in ref-guide >> and link to the ref-guide from the release-note. I.e. ref-guide currently >> ways DIH is to be removed, perhaps that page could instead explain how to >> obtain the package, and at the same time encourage users to contribute to >> maintaining it? >> >> The consensus from yesterday seems to be that stuff with a released >> replacement can/should be removed in 9.0, but for CDCR and SolrCell, where >> the proejct still wants to provide a better alternative, they can remain >> deprecated 9.x. In particular for SolrCell we can’t imagine how many users >> it has out there. Even after inventing its successor based on TikaServer, >> integrated in SolrJ or whatever, I would advocate for the good-old >> ExtractingRequestHandler to be available as a package for a few releases to >> come. >> >> Wrt whether something could be removed in 9.1 as long as it was deprecated >> in 8.x, I would initially say YES, at least legally/technically. We’re not >> breaking any back-compat promise as long as it has been prominently flagged >> as deprecated for so long. However, I can see how people not reading >> documentation downloads 9.0.0, starts using a deprecated feature and then >> complains when it is gone in 9.3 :) >> >> We also have an option to release Solr 10.0 (Solr X) sooner rather than >> 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 page? >> >> Jan >> >> 28. aug. 2020 kl. 07:43 skrev David Smiley <[email protected]>: >> >> >> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya >> <[email protected]> wrote: >>> >>> > I find it highly depressing that we can't, *in a major release*, manage >>> > to get rid of our deprecations -- particularly for code that has a new >>> > home and is packaged in a form that is trivial to install (thanks to our >>> > new awesome package manager). >>> >>> I'm not sure why you think "we can't". I can't even remember a single >>> committer standing in the way of removing those *that already have a >>> package*. >> >> >> Okay, maybe I read the intent wrong. I can see the example given was about >> Solr Cell, which apparently has no new home, so I'm +0 with keeping it for >> 9.0. >> >> Also, on the roadmap cwiki: >> >>> We should not remove all features/APIs deprecated in 8.x yet, to give users >>> a path to upgrade to 9.x without all the extra noise. Deprecated features >>> can be removed in a later 9.x release, when the new alternative is solid >>> and well known. >> >> >> Again, maybe I'm misreading but I'd like to us to manage to remove a lot of >> deprecated stuff as the norm. There will be exceptions to the norm -- Solr >> Cell, CDCR. To make this point clear, I wish to add to the roadmap, Solr >> 9.0 table, first row, saying basically "Remove lots of deprecated stuff" >> with some JIRAs linked like https://issues.apache.org/jira/browse/SOLR-13138 >> >> ~ David >> >> -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
