If CDCR is actively broken (does not start?), then isn't it effectively deprecated from the last version that did not work? And if it is not going to be maintained, then isn't the 'latest' version is whichever we still did not delete it in. Because a broken feature is only worth keeping in, if we ever plan to fix it.
We have been through the same with UIMA, if I recall. It was broken for a bit and then when I pulled it, ONE person got all upset. SOLR-11694 Regards, Alex 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 <ichattopadhy...@gmail.com> 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*. However, there's a backlash against removing CDCR even though there > is no one volunteering to support it (as a package) and it is clearly broken, > which is what totally puzzles me. > https://issues.apache.org/jira/browse/SOLR-14616 > > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <arafa...@gmail.com> > wrote: >> >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily >> learning magic gradle commands to make that happen without leaving >> behind random crumbs. Once that lands, I will do Jira search on all >> DIH still-open tasks after that and close them pointing to the said >> Jira. >> >> So, I guess somebody better -1 the Jira if they really want that one >> to stay until ... ? And then read very carefully through SIP-10 of >> which, this is just a first step. >> >> In general, maybe we can manage to do so many new features and cleanup >> in 9 that will make Solr TLP look like a great Big Bang moment... >> >> And it will probably take a little longer to achieve that, so the - >> effective - deprecation schedule would still be ok. >> >> Regards, >> Alex. >> >> On Thu, 27 Aug 2020 at 18:35, David Smiley <dsmi...@apache.org> wrote: >> >> >> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, >> >> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and >> >> then have yet some time to change their processes to adapt to the new way >> >> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of >> >> deprecated code, but I think it is a mistake to do all of the proposed >> >> removals at once. We can spread removals out in 9.x releases, after users >> >> have had a few releases with a choice between old and new and the new >> >> alternative is solid. >> > >> > >> > 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 sympathetic to waiting to delete until >> > *after* there is an actual package ready at that time (rather than just >> > the promise of one). >> > >> > Also, users generally are cautious on performing a major version upgrade. >> > There's time. >> > >> > ~ David Smiley >> > Apache Lucene/Solr Search Developer >> > http://www.linkedin.com/in/davidwsmiley >> > >> > >> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <jan....@cominvent.com> wrote: >> >> >> >> I edited the page to introduce the (super important) Solr TLP split into >> >> the roadmap. >> >> Also added a rough timeframe and a «major theme» for each release above >> >> the issue table. >> >> I added 8.8 and 9.1 as I think it is important to track what gets done >> >> just before 9.0 and what can be deferred to after 9.0. >> >> >> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, >> >> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and >> >> then have yet some time to change their processes to adapt to the new way >> >> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of >> >> deprecated code, but I think it is a mistake to do all of the proposed >> >> removals at once. We can spread removals out in 9.x releases, after users >> >> have had a few releases with a choice between old and new and the new >> >> alternative is solid. >> >> >> >> Thanks Gus for taking ownership and suggesting a process! Feel free to >> >> rework what I edited into a structure you see more fit. >> >> >> >> Jan >> >> >> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gus.h...@gmail.com>: >> >> >> >> I was thinking that level of detail is in the Jira... I don't see any >> >> reason for things to disappear (in fact rejected should go in a rejected >> >> list for future reference.) >> >> >> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <ilans...@gmail.com> wrote: >> >>> >> >>> Maybe also add “in progress”? So items do not disappear suddenly from >> >>> the page when work really starts on them? >> >>> >> >>> On Tue 11 Aug 2020 at 17:15, Gus Heck <gus.h...@gmail.com> wrote: >> >>>> >> >>>> Cool, since I brought it up, I can volunteer to help manage the page. >> >>>> We should get jira issue links in there wherever possible. Do we want >> >>>> to build an initial list and have some sort of Proposed/Planned >> >>>> workflow so readers can have confidence (or appropriate lack of >> >>>> confidence) in what they see there? voting on things seems like too >> >>>> much but maybe folks who care watch the page, and if something is on >> >>>> there for a week without objection it can be called accepted? If a >> >>>> discussion starts here it can be marked "Considering" so... something >> >>>> like this: >> >>>> >> >>>> 4 states: Proposed, Considering, Planned, Rejected >> >>>> >> >>>> Workflow like this: >> >>>> Proposed -------(no objection 1 wk) --> Planned >> >>>> Proposed -------(discussion)----------> Considering >> >>>> Considering ----(agreement) ----------> Planned >> >>>> Considering ----(deferred) -----------> Proposed (later release) >> >>>> Considering ----(unsuitable) ---------> Rejected >> >>>> Considering ----(promoted) -----------> Proposed (earlier 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 Considering) can be overridden by a >> >>>> formal vote of course >> >>>> >> >>>> -Gus >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Tue, Aug 11, 2020 at 10:29 AM Ishan Chattopadhyaya >> >>>> <ichattopadhy...@gmail.com> wrote: >> >>>>> >> >>>>> I've created a placeholder document here: >> >>>>> https://cwiki.apache.org/confluence/display/SOLR/Roadmap >> >>>>> Let us put in all our items there. >> >>>>> >> >>>>> On Tue, Aug 11, 2020 at 4:45 PM Jan Høydahl <jan....@cominvent.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Let’s revive this email thread about Roadmap. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> With so many large initiatives going on, and the TLP split also, I >> >>>>>> think it makes perfect sense with a Roadmap. >> >>>>>> >> >>>>>> >> >>>>>> I know we’re not used to that kind of thing - we tend to just let >> >>>>>> things play out as it happens to land in various releases, but this >> >>>>>> time is special, and I think we’d benefit from more coordination. I >> >>>>>> don’t know how to enforce such coordination though, other than >> >>>>>> appealing to all committers to endorse the roadmap and respect it >> >>>>>> when they merge things. We may not be able to set a release date for >> >>>>>> 9.0 right now, but we may be able to define preconditions and scope >> >>>>>> certain features to 9.0 or 9.1 rather than 8.7 or 8.8 - that kind of >> >>>>>> coarse-grained decisions. We also may need a person that «owns» the >> >>>>>> Roadmap confluence page and actively promotes it, tries to keep it up >> >>>>>> to date and reminds the rest of us about its existence. A roadmap >> >>>>>> must NOT be a brake slowing us down, but a tool helping us avoid >> >>>>>> silly mistakes. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Jan >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> > 5. jul. 2020 kl. 02:39 skrev Noble Paul <noble.p...@gmail.com>: >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > I think the logical thing to do today is completely rip out all >> >>>>>> >> >>>>>> >> >>>>>> > autoscaling code as it exists today. >> >>>>>> >> >>>>>> >> >>>>>> > Let's deprecate that in 8.7 and build something for >> >>>>>> > "assign-strategy". >> >>>>>> >> >>>>>> >> >>>>>> > Austoscaling , if required, should not be a part of Solr >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > On Fri, Jul 3, 2020 at 5:48 PM Jan Høydahl <jan....@cominvent.com> >> >>>>>> > wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> +1 >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> Why don’t we make a Roadmap wiki page as Cassandra suggests, and >> >>>>>> >> indicate what major things needs to happen when. >> >>>>>> >> >>>>>> >> >>>>>> >> Perhaps if we can get the Solr TLP and git-split ball rolling as a >> >>>>>> >> pre-9.0 task, then perhaps 8.8 could be the last joint release >> >>>>>> >> (6.6, 7.7, 8.8 hehe)? >> >>>>>> >> >>>>>> >> >>>>>> >> That would enable Lucene to ship 9.0 without waiting for a ton of >> >>>>>> >> alpha-quality Solr features, and Solr could have its own Roadmap >> >>>>>> >> wiki. >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> Jan >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> 3. jul. 2020 kl. 09:19 skrev Dawid Weiss <dawid.we...@gmail.com>: >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >>> I totally expect some things to bubble up when we try to release >> >>>>>> >>> with Gradle, the tarball being one. I don’t think that’s a very >> >>>>>> >>> big issue, but if you have lots of “not very big” issues they do >> >>>>>> >>> add up. >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> Adding a tarball is literally 3-5 lines of code (you add a task >> >>>>>> >> that builds a tarball or a zip file from the outputs of >> >>>>>> >> solr/packaging toDir task)... The bigger issue with gradle is that >> >>>>>> >> somebody has to step up and try to identify any other issues >> >>>>>> >> and/or missing bits when trying to do a full release cycle. >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> D. >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > -- >> >>>>>> >> >>>>>> >> >>>>>> > ----------------------------------------------------- >> >>>>>> >> >>>>>> >> >>>>>> > Noble Paul >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> > --------------------------------------------------------------------- >> >>>>>> >> >>>>>> >> >>>>>> > 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 >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> http://www.needhamsoftware.com (work) >> >>>> http://www.the111shift.com (play) >> >>>> >> >>>> >> >> >> >> >> >> -- >> >> http://www.needhamsoftware.com (work) >> >> http://www.the111shift.com (play) >> >> >> >> >> >> --------------------------------------------------------------------- >> 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
