I perfectly agree, I can give another cleanup next week before the merge, but I am not entirely sure I can avoid to touch at all some of those monster classes.
Maybe we need another line of work, as we were discussing before, to make in general Solr more modular. I'll be at the committer meetup anyway, so see you there! On Sat, 15 Jan 2022, 00:37 Jan Høydahl, <jan....@cominvent.com> wrote: > Good points. Yea, changes could be generated from JIRA with > releasedocmaker from Yetus, although it is not perfect either. > > It would be less worrying to add new things only to main such as neural > search, if such a feature could be added to Solr either as > a contrib module / package or at least as only new files, new tests etc. > > But looking at the PR, we see that our core lacks modularity in several > places, where you need to edit monster classes that are not pluggable. > > - SchemaCodecFactory.java > - QParserPlugin.java (for wiring in QParsers with their short name) > - DocumentBuilder.java (instanceOf checks on specific FieldTypes, > validation. Instead, the builder should call out to the fieldTypes in use > for validation?) > - Tests are intermingled with other core tests, with monster collection1 > schema ever growing. We have talked about tests using config-api and > schema-api instead. > > I think as we start eating our own dogfood, extracting more plugins from > core, we'll have to deal with some of this tech debt. > > Jan > > 14. jan. 2022 kl. 23:56 skrev David Smiley <dsmi...@apache.org>: > > I like letting features bake in main & 9x! > I don't plan to merge anything to 9.0 until after the committer meeting, > and then will do a dev list follow-up so anyone can weigh in if they didn't > attend. > > Two problems: > (1) CHANGES.txt management has always been a pain (IMO) and it could be > here especially if we don't even know if it's going to make 9.0 initially. > We'd have to move the bullets around and do extra commits and deal with the > merge issues (albeit minor). We could deliberately not add some > CHANGES.txt entries until the release inclusion decision is made? (an > aside: removing the CHANGES.txt in lieu of other things that mostly exist > would be awesome but I digress. > (2) Some changes should be made in a major release only. I suppose > it could then simply stay in main... but if it's big/impactful then the > timing is terrible for our backports over the next year. Oh well, I guess. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Jan 14, 2022 at 2:59 PM Jan Høydahl <j...@cominvent.com> wrote: > >> Thanks for being so structured and transparent about your proposals, >> David. I'll not comment on each JIRA here but reply to your "approval" >> question. >> >> As RM my primary concern is to see to that the release happens, in due >> time, with good quality and with no last-minute changes that causes >> instability. >> I do NOT have a need to display authority as RM, by pretending to know >> better than anyone else what is best for the project. >> So I'll likely respect any consensus from the committer's meeting next >> week wrt JIRAs to add as blockers for 9.0. >> >> I'm pleased to see the momentum on wrapping things up, this is exactly >> how preparing for a major release in a healthy project should be. >> We all now realize that we have to let go of some hopes we had for 9.0. >> Still, many impactful changes are still within reach if they are not too >> intrusive. >> I think starting a new thread here on dev@ for each proposal has worked >> really well so far. Perhaps tag the subject with [9.0 PROPOSAL] ? >> >> Wrt branches, let's utilize the main -> branch_9x -> if(blocker) { >> branch_9_0 } workflow. >> It is much easier to advocate for a blocker if it has baked in main for a >> week or two! >> >> Jan >> >> >> 14. jan. 2022 kl. 05:47 skrev David Smiley <dsmi...@apache.org>: >> >> 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? >> >> Observability: >> * https://issues.apache.org/jira/browse/SOLR-14686 Remove log >> "[coreName]" (logid) which is redundant with MDC >> -- PR just updated and tagged some possible reviewers. No feedback yet >> :-/ I'll merge soon. >> * https://issues.apache.org/jira/browse/SOLR-15905 "Don't automatically >> register Solr's metrics with JMX (SolrJmxReporter)" >> -- Yet our default solr.xml could keep it?. ETA Jan 24 >> * https://issues.apache.org/jira/browse/SOLR-14401 ""distrib" request >> handler metrics should only be tracked on pertinent handlers" >> -- Looking for some feedback on the issue first. ETA Jan 24 >> >> Highlighting: >> * https://issues.apache.org/jira/browse/SOLR-15259 lower default >> hl.fragAlignRatio >> -- minor change but better to change highlighting fragment defaults in a >> major release but not critical. ETA: Jan 17 >> * https://issues.apache.org/jira/browse/SOLR-12901 Make >> UnifiedHighlighter the default >> -- There are some overlaps between the highlighters but I definitely >> think the UH is the best highlighter. ETA Jan 21 >> -- separate issue, TBD: removing the big/verbose configs for the other >> highlighters from the default solrconfig.xml to keep it leaner. >> >> Docker: >> * JIRA TBD, Java 17 runtime. ETA Jan 17 >> >> Filter.java; remove/hide >> * https://issues.apache.org/jira/browse/SOLR-12336 "Remove Filter from >> Solr" >> -- a contributor has something but is getting approval. If we don't get >> this in time, I could do something simple to just ensure the class isn't >> public. >> >> Nested Docs: >> * https://issues.apache.org/jira/browse/SOLR-15064 "Atomic/partial >> updates to nested docs should not assume _route_ param is the root ID" >> -- Debt/confusion to be removed. ETA 21 Jan >> >> Modularizing: >> * Solrj-Zookeeper: ETA Jan 17 >> * https://issues.apache.org/jira/browse/SOLR-14660 HDFS (or Hadoop?) >> -- Waiting for the contributor to return to it. See the issue for >> discussion on what to do if it stagnates further. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> >
