Noble, we all agree on those principles and that direction. But 9.0 is not the last chance to remove things. I think we must decide on a feature-by feature basis: - Whether the feature should remain a ASF maintained feature or not - If yes, we should make it into a 1st party package distributed in our own repo - If no, we must decide what is the right time to remove it from the distro. - If an alternative package already exists, it can be removed in next major - If not, we must decide how long time our users need to prepare an alternative (3rd party pkg or home-grown)
When propose to stop maintaining a feature as part of the project, a [VOTE] thread is an excellent way to make such a decision. Jan > 28. aug. 2020 kl. 14:35 skrev Noble Paul <[email protected]>: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
