Re: [JENKINS] Lucene » Solr-Artifacts-8.x - Build # 114 - Failure!
Apologies for breaking branch 8.x with my cherry-pick, double checking things locally and will push a fix shortly. On Mon, Nov 30, 2020 at 2:53 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > Build: https://ci-builds.apache.org/job/Lucene/job/Solr-Artifacts-8.x/114/ > > No tests ran. > > Build Log: > [...truncated 2393 lines...] > [javac] Compiling 1360 source files to > /home/jenkins/jenkins-slave/workspace/Lucene/Solr-Artifacts-8.x/solr/build/solr-core/classes/java > [javac] > /home/jenkins/jenkins-slave/workspace/Lucene/Solr-Artifacts-8.x/solr/core/src/java/org/apache/solr/core/CachingDirectoryFactory.java:329: > error: cannot find symbol > [javac] Path dirPath = Path.of(path); > [javac]^ > [javac] symbol: method of(String) > [javac] location: interface Path > [javac] Note: Some input files use or override a deprecated API. > [javac] Note: Recompile with -Xlint:deprecation for details. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > [javac] 1 error > > BUILD FAILED > /home/jenkins/jenkins-slave/workspace/Lucene/Solr-Artifacts-8.x/solr/build.xml:506: > The following error occurred while executing this line: > /home/jenkins/jenkins-slave/workspace/Lucene/Solr-Artifacts-8.x/solr/common-build.xml:406: > The following error occurred while executing this line: > /home/jenkins/jenkins-slave/workspace/Lucene/Solr-Artifacts-8.x/lucene/common-build.xml:581: > The following error occurred while executing this line: > /home/jenkins/jenkins-slave/workspace/Lucene/Solr-Artifacts-8.x/lucene/common-build.xml:2083: > Compile failed; see the compiler error output for details. > > Total time: 54 seconds > Build step 'Invoke Ant' marked build as failure > Archiving artifacts > Publishing Javadoc > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any > > - > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > For additional commands, e-mail: builds-h...@lucene.apache.org
Re: DIH replacement
Check out this ticket: https://issues.apache.org/jira/browse/SOLR-14673 There are lots of different ways that this could be applied as a replacement for DIH. Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Nov 30, 2020 at 9:56 AM Erick Erickson wrote: > For what I suggested, there’s no code to write, these streams exist > already. > > As far as supporting the more complex cases… I’m -1 for adding special > code to streaming. DIH has many moving parts. Each of those parts was put > there for a reason, and needed to be supported through successive Solr > releases. What I specifically do _not_ want to do is to start down the path > of reproducing those parts with special-purpose streaming code that tries > to replace DIH with equivalent streaming functionality. > > I think it’s kinder to end users to set expectations that they need to be > responsible for the ETL process. If there is streaming capabilities that do > the needful, they can certainly use them rather than write something > themselves. Otherwise they need to create an independent ETL process. > > The origin of this thought was the realization that streaming can import > from a DB as-is, one of the base use-cases for DIH. On a quick look, I > don’t see any other streams that work with other data sources, say a > TikaStream, a FileStream, etc... > > FWIW, > Erick > > > > On Nov 29, 2020, at 11:52 AM, Atri Sharma wrote: > > > > FWIW i am interested in this -- happy to collaborate > > > > On Sun, 29 Nov 2020, 22:07 Erick Erickson, > wrote: > > How far can we get in replacing DIH with streams? I can write a simple > DIH implementation by wrapping a jdbc stream in an update stream for > instance (I think). > > > > It falls down with some of the more complex DIH constructs, but the > simple “pull data from the DB and insert it into Solr” case seems covered... > > - > > 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 > >
Re: DIH replacement
For what I suggested, there’s no code to write, these streams exist already. As far as supporting the more complex cases… I’m -1 for adding special code to streaming. DIH has many moving parts. Each of those parts was put there for a reason, and needed to be supported through successive Solr releases. What I specifically do _not_ want to do is to start down the path of reproducing those parts with special-purpose streaming code that tries to replace DIH with equivalent streaming functionality. I think it’s kinder to end users to set expectations that they need to be responsible for the ETL process. If there is streaming capabilities that do the needful, they can certainly use them rather than write something themselves. Otherwise they need to create an independent ETL process. The origin of this thought was the realization that streaming can import from a DB as-is, one of the base use-cases for DIH. On a quick look, I don’t see any other streams that work with other data sources, say a TikaStream, a FileStream, etc... FWIW, Erick > On Nov 29, 2020, at 11:52 AM, Atri Sharma wrote: > > FWIW i am interested in this -- happy to collaborate > > On Sun, 29 Nov 2020, 22:07 Erick Erickson, wrote: > How far can we get in replacing DIH with streams? I can write a simple DIH > implementation by wrapping a jdbc stream in an update stream for instance (I > think). > > It falls down with some of the more complex DIH constructs, but the simple > “pull data from the DB and insert it into Solr” case seems covered... > - > 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
Re: SOLR: Why do we have a CHANGES.txt/md to maintain?
I get your point on different audiences... sometimes I peer-review us on dubiously written CHANGES.txt entries to be more user friendly. However, this attention could and should be given to JIRA issue summaries as well. We all benefit from that. Also, for Solr in particular, the need for examining CHANGES / JIRA is reduced because we have a solr-upgrade-notes.adoc which is editorialized and covers just the important stuff; no minor matters. We link to this from release announcements. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Nov 30, 2020 at 3:29 AM Adrien Grand wrote: > I have a preference for maintaining a separate CHANGES file because it > allows us to keep JIRA focused for a committer/contributor audience while > the CHANGES file can describe changes that matter for users. Elasticsearch > uses a similar mechanism for release notes to what you are proposing, using > GitHub instead of JIRA. It works well, but in my opinion the Lucene/Solr > process produces better curated release notes. > > On Mon, Nov 30, 2020 at 12:25 AM David Smiley wrote: > >> Well the commit history remains there as well and was converted from SVN >> and may eventually be converted to something else. My point is that it has >> been retained. On release boundaries, we could not only distribute >> Changes.html (a JIRA export) in the assembly (tar.gz) but we could also >> commit it to source control on each release branch, and thus will transfer >> along with source control into the future, which is way more convenient >> than digging up an old binary. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Sun, Nov 29, 2020 at 5:55 AM Dawid Weiss >> wrote: >> >>> Changes in the repository stay there forever (think >>> cvs/svn/git/whatever comes next...). External tools change all the >>> time. This is the benefit I see. >>> >>> Dawid >>> >>> On Sun, Nov 29, 2020 at 6:32 AM David Smiley wrote: >>> > >>> > After recently proposing per-module CHANGES.md... I think I'd actually >>> rather not have any CHANGES file at all to maintain. I'd rather go to JIRA >>> with a bit better hygiene for metadata like components==contrib/module, and >>> have some convenient links sprinkled about so that it's a convenient click >>> away from each module. This proposal may not be as compelling for Lucene >>> which has no solr-upgrade-notes.adoc file. >>> > >>> > Maintaining this CHANGES file (or files) is a pain. Formatting it >>> just-so & conversion to HTML & other scripts manipulating it in dev-tools >>> (e.g. add version), and branch syncing. It's commonly a source of merge >>> conflicts more than any other file. It's an annoying step with GitHub PRs >>> in particular. Why do we bother? Instead, on releases, provide a JIRA >>> link to display all fixed issues grouped by issue type. We could export it >>> to a file for direct inclusion in the distribution. JIRA even has a >>> feature for this -- here's a direct link for 8.7: >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310230=12348463 >>> Notice the HTML version at the bottom. It could be dumped into the release >>> binaries. >>> > Issue summaries tend to be much shorter than CHANGES.txt bullets but I >>> think that's okay because it's not the only information available for those >>> who want to know more. Remember there is also all the other metadata in >>> JIRA a user can examine, there are commit messages, sometimes PRs, and >>> there's solr-upgrade-notes.adoc which ought to be the starting point for >>> someone interested in a release. >>> > >>> > It's been argued that contributors should get attribution here but we >>> could maintain a separate contributors file to acknowledge people by name >>> for inclusion with the Solr distribution -- one that has a link to JIRA and >>> GitHub even. >>> > >>> > ~ 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 >>> >>> > > -- > Adrien >
RE: Approach towards solving split package issues?
Hi, You can have both in same JAR file. No need to split releases, this would confuse users even more. For some stuff you just have to make sure that both usage possibilities are available, but in general the Gradle build should switch to "module" compilation mode, so all dependencies are checked by javac and the output is a module-compliant JAR file. The only special case I know of regarding discovery and usage of JAR files is Service provider files: They need to be in META-INF/services for classpath use cases, but they also need to be in module descriptor for module projects. If we use the gradle module plugin, we must make sure that the render-javadocs task also uses modulepath not classpath. I have no idea about ECJ But when adding module descriptors, we need at least a basic test that the module descriptors work, services work and a basic project compiles and builds (kinda integration test). Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dawid Weiss > Sent: Monday, November 30, 2020 11:51 AM > To: Lucene Dev > Subject: Re: Approach towards solving split package issues? > > I think it'd be fun to switch to the module system at some point. > Perhaps offer dual release, initially (modules + JARs). > > Dawid > > On Mon, Nov 30, 2020 at 10:37 AM Uwe Schindler wrote: > > > > Hi, > > > > I wanted to just add: > > We also need some testing of the artifacts! Our standard test environment > can't do testing of module system. This needs some "integration" tests: A > project using the JAR files on module path - no classpath. And here it must be > JAR files, the non-packaged class files won't work as far as I remember. > > > > When doing this, you will figure out that the SPI classes (codecs, > > analyzers) > won't work on module path. Because we do not only need to open the > packages in our modules, the contents on META-INF/servisices need to be > added as "native services" to the module info. Every module-info file must > list > all class names that are services explicit. The META-INF/service files are not > read in module mode: > > > > See this blog post: https://blog.frankel.ch/migrating-serviceloader-java-9- > module-system/ > > > > I am not sure if JDEPS figures this out automatically! > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > -Original Message- > > > From: Dawid Weiss > > > Sent: Saturday, November 28, 2020 9:52 PM > > > To: Lucene Dev > > > Subject: Re: Approach towards solving split package issues? > > > > > > I'm not an expert on modules either - haven't had the need to use > > > them. But then: it's part of the fun to discover new things. I don't > > > see the reason why we shouldn't do it (on master). > > > > > > Dawid > > > > > > On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida > > > wrote: > > > > > > > > On second thought... > > > > Adding module-info.java to all sub-modules seems to be a relatively > simple > > > task (though it might involve laborious work), however, properly > maintaining > > > them would not be so trivial I suspect. I'm not sure developers (including > me) > > > are ready for the module system. Introducing it right now could put > > > another > > > burden on us? > > > > > > > > I'm not an expert in this area. What do you think? > > > > > > > > Tomoko > > > > > > > > > > > > 2020年11月26日(木) 19:48 Dawid Weiss : > > > >> > > > >> I think this sounds good! > > > >> D. > > > >> > > > >> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida > > > >> wrote: > > > >> > > > > >> > > The check could be implemented (crudely) by looking at java > > > >> > > sourceSets, scanning which folders *.java files live in (packages) > > > >> > > and > > > >> > > then checking for conflicts at the top-level project? > > > >> > > > > >> > I opened LUCENE-9604 some days ago, I've done nothing yet for it. > > > >> > > > > >> > Maybe we can add a precommit check to find split packages using > Gradle > > > APIs, but - how about having module-info.java now instead of an ad-hoc > > > temporary solution (though I don't know if there is another issue to be > > > considered)? > > > >> > As a starter, we could open up (export) all existing packages... > > > >> > > > > >> > > > > >> > 2020年11月12日(木) 0:51 Dawid Weiss : > > > >> >> > > > >> >> Thanks Tomoko! > > > >> >> > > > >> >> The check could be implemented (crudely) by looking at java > > > >> >> sourceSets, scanning which folders *.java files live in (packages) > > > >> >> and > > > >> >> then checking for conflicts at the top-level project? > > > >> >> > > > >> >> The test framework needs to be package-split to see core internals? > > > >> >> > > > >> >> Dawid > > > >> >> > > > >> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida > > > >> >> wrote: > > > >> >> > > > > >> >> > I closed LUCENE-9499, which means we now have no split
Re: Approach towards solving split package issues?
I think it'd be fun to switch to the module system at some point. Perhaps offer dual release, initially (modules + JARs). Dawid On Mon, Nov 30, 2020 at 10:37 AM Uwe Schindler wrote: > > Hi, > > I wanted to just add: > We also need some testing of the artifacts! Our standard test environment > can't do testing of module system. This needs some "integration" tests: A > project using the JAR files on module path - no classpath. And here it must > be JAR files, the non-packaged class files won't work as far as I remember. > > When doing this, you will figure out that the SPI classes (codecs, analyzers) > won't work on module path. Because we do not only need to open the packages > in our modules, the contents on META-INF/servisices need to be added as > "native services" to the module info. Every module-info file must list all > class names that are services explicit. The META-INF/service files are not > read in module mode: > > See this blog post: > https://blog.frankel.ch/migrating-serviceloader-java-9-module-system/ > > I am not sure if JDEPS figures this out automatically! > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Dawid Weiss > > Sent: Saturday, November 28, 2020 9:52 PM > > To: Lucene Dev > > Subject: Re: Approach towards solving split package issues? > > > > I'm not an expert on modules either - haven't had the need to use > > them. But then: it's part of the fun to discover new things. I don't > > see the reason why we shouldn't do it (on master). > > > > Dawid > > > > On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida > > wrote: > > > > > > On second thought... > > > Adding module-info.java to all sub-modules seems to be a relatively simple > > task (though it might involve laborious work), however, properly maintaining > > them would not be so trivial I suspect. I'm not sure developers (including > > me) > > are ready for the module system. Introducing it right now could put another > > burden on us? > > > > > > I'm not an expert in this area. What do you think? > > > > > > Tomoko > > > > > > > > > 2020年11月26日(木) 19:48 Dawid Weiss : > > >> > > >> I think this sounds good! > > >> D. > > >> > > >> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida > > >> wrote: > > >> > > > >> > > The check could be implemented (crudely) by looking at java > > >> > > sourceSets, scanning which folders *.java files live in (packages) > > >> > > and > > >> > > then checking for conflicts at the top-level project? > > >> > > > >> > I opened LUCENE-9604 some days ago, I've done nothing yet for it. > > >> > > > >> > Maybe we can add a precommit check to find split packages using Gradle > > APIs, but - how about having module-info.java now instead of an ad-hoc > > temporary solution (though I don't know if there is another issue to be > > considered)? > > >> > As a starter, we could open up (export) all existing packages... > > >> > > > >> > > > >> > 2020年11月12日(木) 0:51 Dawid Weiss : > > >> >> > > >> >> Thanks Tomoko! > > >> >> > > >> >> The check could be implemented (crudely) by looking at java > > >> >> sourceSets, scanning which folders *.java files live in (packages) and > > >> >> then checking for conflicts at the top-level project? > > >> >> > > >> >> The test framework needs to be package-split to see core internals? > > >> >> > > >> >> Dawid > > >> >> > > >> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida > > >> >> wrote: > > >> >> > > > >> >> > I closed LUCENE-9499, which means we now have no split packages in > > lucene (except for test-framework). > > >> >> > Please keep in mind we still don't have any static > > >> >> > analysis/validations to > > prevent someone from adding another package name conflicts between > > modules. > > >> >> > > > >> >> > > > >> >> > 2020年11月5日(木) 19:38 Tomoko Uchida > > : > > >> >> >> > > >> >> >> Hi, > > >> >> >> please review LUCENE-9600, this cleans up split packages in "misc" > > module and makes some refactoring on classes in lucene/misc to keep > > lucene/core unchanged. > > >> >> >> > > >> >> >> Tomoko > > >> >> >> > > >> >> >> > > >> >> >> 2020年10月24日(土) 19:25 Tomoko Uchida > > : > > >> >> >>> > > >> >> >>> Hi, > > >> >> >>> please review LUCENE-9319. This tries to resolve package name > > conflicts between "sandbox" and "core" modules. > > >> >> >>> Looks like many eyeballs are needed for cleaning up our sandbox. > > >> >> >>> > > >> >> >>> Tomoko > > >> >> >>> > > >> >> >>> > > >> >> >>> 2020年10月18日(日) 0:36 Tomoko Uchida > > : > > >> >> > > >> >> Hi, > > >> >> please review LUCENE-9318, this refactors backward-codecs module > > (packages are renamed). > > >> >> I'm going to merge it into the master after waiting a week or so > > >> >> if > > there is no objection/feedback. > > >> >> > > >> >> Tomoko > > >> >> > > >> >> > > >> >> 2020年9月3日(木) 22:35 Tomoko Uchida > > : > > >> >> > > > >> >>
RE: Approach towards solving split package issues?
Hi, I wanted to just add: We also need some testing of the artifacts! Our standard test environment can't do testing of module system. This needs some "integration" tests: A project using the JAR files on module path - no classpath. And here it must be JAR files, the non-packaged class files won't work as far as I remember. When doing this, you will figure out that the SPI classes (codecs, analyzers) won't work on module path. Because we do not only need to open the packages in our modules, the contents on META-INF/servisices need to be added as "native services" to the module info. Every module-info file must list all class names that are services explicit. The META-INF/service files are not read in module mode: See this blog post: https://blog.frankel.ch/migrating-serviceloader-java-9-module-system/ I am not sure if JDEPS figures this out automatically! Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dawid Weiss > Sent: Saturday, November 28, 2020 9:52 PM > To: Lucene Dev > Subject: Re: Approach towards solving split package issues? > > I'm not an expert on modules either - haven't had the need to use > them. But then: it's part of the fun to discover new things. I don't > see the reason why we shouldn't do it (on master). > > Dawid > > On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida > wrote: > > > > On second thought... > > Adding module-info.java to all sub-modules seems to be a relatively simple > task (though it might involve laborious work), however, properly maintaining > them would not be so trivial I suspect. I'm not sure developers (including me) > are ready for the module system. Introducing it right now could put another > burden on us? > > > > I'm not an expert in this area. What do you think? > > > > Tomoko > > > > > > 2020年11月26日(木) 19:48 Dawid Weiss : > >> > >> I think this sounds good! > >> D. > >> > >> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida > >> wrote: > >> > > >> > > The check could be implemented (crudely) by looking at java > >> > > sourceSets, scanning which folders *.java files live in (packages) and > >> > > then checking for conflicts at the top-level project? > >> > > >> > I opened LUCENE-9604 some days ago, I've done nothing yet for it. > >> > > >> > Maybe we can add a precommit check to find split packages using Gradle > APIs, but - how about having module-info.java now instead of an ad-hoc > temporary solution (though I don't know if there is another issue to be > considered)? > >> > As a starter, we could open up (export) all existing packages... > >> > > >> > > >> > 2020年11月12日(木) 0:51 Dawid Weiss : > >> >> > >> >> Thanks Tomoko! > >> >> > >> >> The check could be implemented (crudely) by looking at java > >> >> sourceSets, scanning which folders *.java files live in (packages) and > >> >> then checking for conflicts at the top-level project? > >> >> > >> >> The test framework needs to be package-split to see core internals? > >> >> > >> >> Dawid > >> >> > >> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida > >> >> wrote: > >> >> > > >> >> > I closed LUCENE-9499, which means we now have no split packages in > lucene (except for test-framework). > >> >> > Please keep in mind we still don't have any static > >> >> > analysis/validations to > prevent someone from adding another package name conflicts between > modules. > >> >> > > >> >> > > >> >> > 2020年11月5日(木) 19:38 Tomoko Uchida > : > >> >> >> > >> >> >> Hi, > >> >> >> please review LUCENE-9600, this cleans up split packages in "misc" > module and makes some refactoring on classes in lucene/misc to keep > lucene/core unchanged. > >> >> >> > >> >> >> Tomoko > >> >> >> > >> >> >> > >> >> >> 2020年10月24日(土) 19:25 Tomoko Uchida > : > >> >> >>> > >> >> >>> Hi, > >> >> >>> please review LUCENE-9319. This tries to resolve package name > conflicts between "sandbox" and "core" modules. > >> >> >>> Looks like many eyeballs are needed for cleaning up our sandbox. > >> >> >>> > >> >> >>> Tomoko > >> >> >>> > >> >> >>> > >> >> >>> 2020年10月18日(日) 0:36 Tomoko Uchida > : > >> >> > >> >> Hi, > >> >> please review LUCENE-9318, this refactors backward-codecs module > (packages are renamed). > >> >> I'm going to merge it into the master after waiting a week or so if > there is no objection/feedback. > >> >> > >> >> Tomoko > >> >> > >> >> > >> >> 2020年9月3日(木) 22:35 Tomoko Uchida > : > >> >> > > >> >> > I also opened SOLR-14826 as the placeholder. I'm not fully sure of > its priority but at least Alexandre expressed an interest in fixing it for > Solr, > thanks. > >> >> > If there is someone who wants to take the ownership, please feel > free to join. I will leave it there until LUCENE-9499 is done anyway. > >> >> > > >> >> > > >> >> > > >> >> > 2020年9月3日(木) 0:12 Tomoko Uchida > : > >> >> >> > >> >> >> I opened LUCENE-9499 as the umbrella. > >>
Re: SOLR: Why do we have a CHANGES.txt/md to maintain?
I have a preference for maintaining a separate CHANGES file because it allows us to keep JIRA focused for a committer/contributor audience while the CHANGES file can describe changes that matter for users. Elasticsearch uses a similar mechanism for release notes to what you are proposing, using GitHub instead of JIRA. It works well, but in my opinion the Lucene/Solr process produces better curated release notes. On Mon, Nov 30, 2020 at 12:25 AM David Smiley wrote: > Well the commit history remains there as well and was converted from SVN > and may eventually be converted to something else. My point is that it has > been retained. On release boundaries, we could not only distribute > Changes.html (a JIRA export) in the assembly (tar.gz) but we could also > commit it to source control on each release branch, and thus will transfer > along with source control into the future, which is way more convenient > than digging up an old binary. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Sun, Nov 29, 2020 at 5:55 AM Dawid Weiss wrote: > >> Changes in the repository stay there forever (think >> cvs/svn/git/whatever comes next...). External tools change all the >> time. This is the benefit I see. >> >> Dawid >> >> On Sun, Nov 29, 2020 at 6:32 AM David Smiley wrote: >> > >> > After recently proposing per-module CHANGES.md... I think I'd actually >> rather not have any CHANGES file at all to maintain. I'd rather go to JIRA >> with a bit better hygiene for metadata like components==contrib/module, and >> have some convenient links sprinkled about so that it's a convenient click >> away from each module. This proposal may not be as compelling for Lucene >> which has no solr-upgrade-notes.adoc file. >> > >> > Maintaining this CHANGES file (or files) is a pain. Formatting it >> just-so & conversion to HTML & other scripts manipulating it in dev-tools >> (e.g. add version), and branch syncing. It's commonly a source of merge >> conflicts more than any other file. It's an annoying step with GitHub PRs >> in particular. Why do we bother? Instead, on releases, provide a JIRA >> link to display all fixed issues grouped by issue type. We could export it >> to a file for direct inclusion in the distribution. JIRA even has a >> feature for this -- here's a direct link for 8.7: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310230=12348463 >> Notice the HTML version at the bottom. It could be dumped into the release >> binaries. >> > Issue summaries tend to be much shorter than CHANGES.txt bullets but I >> think that's okay because it's not the only information available for those >> who want to know more. Remember there is also all the other metadata in >> JIRA a user can examine, there are commit messages, sometimes PRs, and >> there's solr-upgrade-notes.adoc which ought to be the starting point for >> someone interested in a release. >> > >> > It's been argued that contributors should get attribution here but we >> could maintain a separate contributors file to acknowledge people by name >> for inclusion with the Solr distribution -- one that has a link to JIRA and >> GitHub even. >> > >> > ~ 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 >> >> -- Adrien
