Absolutely. What I was trying to say is that when it comes to implementation, there may be a choice of strategies to do so within the same scope. A strategy that aligns better with something that - with more work - eventually becomes true structured data may have more long-term value than a strategy that does not.
Hope that makes sense. Regards, Alex. On Tue, 24 Nov 2020 at 12:13, David Smiley <dsmi...@apache.org> wrote: > > I'd rather not scope-creep my proposal here further. Granted I ventured into > TXT -> Markdown. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Nov 24, 2020 at 9:37 AM Alexandre Rafalovitch <arafa...@gmail.com> > wrote: >> >> And - afterthought - if there is an easily parsable format, the parser >> could even run at the commit time on GitHub to make sure that issue >> numbers are correct, names are included and formatting is not broken. >> >> Regards, >> Alex. >> >> On Mon, 23 Nov 2020 at 19:38, Alexandre Rafalovitch <arafa...@gmail.com> >> wrote: >> > >> > Should we switch to a structured format, instead of current format that >> > tools struggle to convert. >> > >> > Something that one could push into Solr would have been nice... >> > >> > Regards, >> > Alex >> > >> > On Mon., Nov. 23, 2020, 4:47 p.m. David Smiley, <dsmi...@apache.org> wrote: >> >> >> >> I pushed a commit to a PR for the prometheus exporter that includes a >> >> CHANGES.md >> >> https://github.com/apache/lucene-solr/pull/1972/commits/bec84ce2a1d60480ce0c54b78e83a70f83e7b058 >> >> and likewise for a commit to a PR for the docker module: >> >> https://github.com/apache/lucene-solr/pull/2083/commits/540f8117153d12bd13441326035820f97084878a >> >> >> >> * I chose the Markdown format. This is an opportune time to switch. >> >> This meant changing "==== 9.0 ====" to "9.0" then "======" beneath it, >> >> but otherwise, no changes! >> >> * I chose to start this for 9.0. Any changes prior to 9.0 I think should >> >> continue to do things as we have been doing things historically. >> >> * I considered updating dev-tools/scripts/addVersion.py but ultimately >> >> elected not to. I think the rate of changes in each module will be low >> >> enough that it's not a big deal to maintain it manually. Plus, I confess >> >> I'm less motivated to touch Python ;-) but I'd be more than happy to see >> >> someone automate this. >> >> >> >> If this is agreeable, Solr's master CHANGES.txt ought to have references >> >> to CHANGES.md for contribs & Docker. >> >> >> >> ~ David Smiley >> >> Apache Lucene/Solr Search Developer >> >> http://www.linkedin.com/in/davidwsmiley >> >> >> >> >> >> On Mon, Nov 23, 2020 at 11:56 AM Houston Putman <houstonput...@gmail.com> >> >> wrote: >> >>> >> >>> +1 >> >>> >> >>> I think that having separate CHANGES.txt files for the different parts >> >>> of Solr would be great. If you are looking for certain changes you would >> >>> generally know which module to go to. >> >>> >> >>>> Some items that have a more sweeping impact would be listed in both >> >>> >> >>> >> >>> I am ambivalent on having a separate CHANGES.txt for SolrJ, as long as >> >>> major changes are included in the main CHANGES.txt. In general it's easy >> >>> to add an entry to every applicable CHANGES.txt, no matter which module >> >>> the change was made in. >> >>> >> >>> - Houston >> >>> >> >>> On Sat, Nov 21, 2020 at 1:34 AM David Smiley <dsmi...@apache.org> wrote: >> >>>> >> >>>> What of Docker changes? And beyond direct changes to Dockerfile + >> >>>> scripts, it could feature particular notable changes to the server that >> >>>> are particularly noteworthy... like hypothetical improvements to solr >> >>>> home / core root dir etc. configuration. >> >>>> >> >>>> Even if Contribs/Modules are not separated out of the repo *yet* (even >> >>>> if they hypothetically never leave), I think it's desirable to separate >> >>>> their CHANGES.txt in master now. >> >>>> >> >>>> RE SolrJ -- I know it's used heavily in the server side; this one is >> >>>> more debatable than the others and I don't have a strong opinion. Some >> >>>> items that have a more sweeping impact (e.g. HTTP2) would be listed in >> >>>> both but the difference is that the SolrJ side would have a more >> >>>> user-facing purpose, mentioning SolrClient subclasses that are >> >>>> pertinent to draw attention to compatibility or new classes users >> >>>> should know about. This kind of stuff is maybe too detailed to bother >> >>>> putting in solr-upgrade-notes.adoc but would not be to SolrJ's >> >>>> dedicated CHANGES.txt. On server CHANGES.txt, we tend to be vague. If >> >>>> SolrJ is changed for something that has more to do with server-side >> >>>> (e.g. SOLR-14691 "Metrics Reporting Should Avoid Creating Objects" >> >>>> which changed some utils in SolrJ), then it ought not to be listed in >> >>>> SolrJ's proposed CHANGES.txt. Admittedly there may be more cumulative >> >>>> CHANGES.txt maintenance between the two. >> >>>> >> >>>> ~ David Smiley >> >>>> Apache Lucene/Solr Search Developer >> >>>> http://www.linkedin.com/in/davidwsmiley >> >>>> >> >>>> >> >>>> On Fri, Nov 20, 2020 at 9:17 PM Ishan Chattopadhyaya >> >>>> <ichattopadhy...@gmail.com> wrote: >> >>>>> >> >>>>> I think whatever we don't ship in the main tarball today should stay >> >>>>> separate. Going forward, when we stop shoving the extra modules >> >>>>> (contribs) into the main distro, we can separate out their changelogs. >> >>>>> However, I feel SolrJ changes should stay with Solr changes since it >> >>>>> is also used heavily in the server side. >> >>>>> >> >>>>> On Sat, 21 Nov, 2020, 3:39 am David Smiley, <dsmi...@apache.org> wrote: >> >>>>>> >> >>>>>> I was about to merge a PR pertaining to Solr's new Docker module when >> >>>>>> it occurred to me that I ought to add a CHANGES.txt entry. But, for >> >>>>>> Solr users (which includes me and everyone reading this), it's >> >>>>>> annoying to have to go to Solr's all-encompassing CHANGES.txt to find >> >>>>>> Docker upgrade notes, which is a distinct way of running Solr. I >> >>>>>> think the same could be said for our contribs, and perhaps even >> >>>>>> SolrJ, which is another distinct consumable. The idea of separated >> >>>>>> CHANGES.txt aligns well with contribs being further isolated (see >> >>>>>> both the discussion on separate git repos for them, and also the >> >>>>>> discussion of getting rid of "dist" (each contrib's jar goes in its >> >>>>>> own folder; keeps to itself)). >> >>>>>> >> >>>>>> Solr's root /CHANGES.txt could at the very top reference the other >> >>>>>> CHANGES.txt files. >> >>>>>> >> >>>>>> WDYT? >> >>>>>> >> >>>>>> ~ David Smiley >> >>>>>> Apache Lucene/Solr Search Developer >> >>>>>> http://www.linkedin.com/in/davidwsmiley >> >> --------------------------------------------------------------------- >> 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
