I lean towards the manual (AI assisted) cleanup approach. There are too many people working across a long release cycle with differing opinions on what is changelog worthy to get it to an automated process that drives a lot of value.
I am also wondering more and more if the changelog is the right way to convey dependency changes? It really quickly becomes a big list of many unknown libraries. I think we need to look at it more from “What do people want to know” in order to understand best way to answer it. For example: “I use SolrJ, what do I need to do to upgrade to the next version”. —> List of SolrJ required dependencies in the Ref Guide. “I use Solr slim bistro, I really care about specific changes”. —> Maybe we should be using a SBOM for this use case? “This is what we actually ship in Solr binary”. “I use a specific module of Solr, what does that drag along”. —> Maybe an SBOM for Solr itself? “I am aware of this CVE in this dependency of Solr, did it get fixed” —> Consult our VEX entries for that dependency and the version of Solr concerned. > On Sep 10, 2026, at 2:49 AM, Jan Høydahl <[email protected]> wrote: > > Thanks for bringing it to the list, we already started discussing this topic > on some solrbot PRs. > > Surprised the wizard still proposes a py script, as it would be duplicating > entries already filed by solrbot on each patch. > And you are correct that, when so much time passes between releases, there > will be solrbot duplicates, or triple or quadruple entries for the same > dependency. > > A better process is needed, but may I suggest a manual (AI assisted) cleanup > for the upcoming release, where you prune duplicates and fix nonsense titles > like the below example. Like back when we had CHANGES.txt I always fixed it > up, removing duplicates or dead meat, rewriting some entries etc. > > Then this thread may hopefully decide an improved process going forward. > Good point though on the shipped vs non-shipped distinction, a test-only or > build-only dependency is obviously not that interesting for a changelog. > > Jan > > > 10. sep. 2026 kl. 04:10 skrev David Smiley <[email protected]>: > > > > Not only does that script generate a bunch of changelog yaml, but we > > already have lots of existing ones. I wish to remove them: > > https://github.com/apache/solr/pull/4895 > > <https://github.com/apache/solr/pull/4895> > > > > On Wed, Sep 9, 2026 at 9:59 PM David Smiley <[email protected]> wrote: > > > >> (I'm writing this in the context of being the release manager for 9.11) > >> > >> It's unclear how I should handle changelogs for dependencies. If I > >> blindly follow the release wizard like a robot, it runs: > >> python3 -u dev-tools/scripts/addDepsToChanges.py --user solrbot > >> --version 9.11.0 > >> Which in turn uses "git log" to find all commits by "solrbot" and converts > >> that commit to a yaml entry. After lots of months, there are *many* yaml > >> files. Many look expected / boring. But then there are some interesting > >> entries such as the following: > >> > >> title: Update all non-major dependencies > >>> type: dependency_update > >>> authors: > >>> - name: solrbot > >>> links: > >>> - name: PR#4597 > >>> url: https://github.com/apache/solr/pull/4597 > >>> <https://github.com/apache/solr/pull/4597> > >>> > >> > >> I *love* that it was one PR for many dependencies instead of a shotgun of > >> commits! But it doesn't even say what it updated exactly; sigh. Imaging > >> searching git log message to find an update and not getting a hit here; > >> ouch! An earlier bulk dependency update at least had a detailed commit > >> message. Now consider that there are other many other solrbot individual > >> updates... which begs the question: how is this to be mixed with those? > >> If I ignore this problem as RM, we have a mismash of partial information. > >> > >> I propose dropping "solrbot" authored changelog entries entirely. Drop > >> this step in the release wizard, drop that python script. The changelog > >> *does* have dependency updates that were interesting enough to be done by > >> (or on behalf of) a named human. > >> > >> I'm in favor of someday maybe adding a single changelog entry per release > >> with a compact list of dependencies that were updated, filtered to those > >> that we actually ship in a binary distribution. But IMO not a priority. > >> > >> ~ David Smiley > >> Apache Lucene/Solr Search Developer > >> http://www.linkedin.com/in/davidwsmiley > >> <http://www.linkedin.com/in/davidwsmiley> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
