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
> 
> 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
>>> 
>> 
>> 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
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to