Thanks for raising the topic, Some history. While we still had CHANGES.txt, it was up to the RM to add changelog entries for dependency updates. We had a py script that would do changelog forensics, de-duplication and spit out a bullet list of what deps were upgraded since the previous git tag.
With the introduction of logchange, we changed so that changelog moved together with each renovate PR, as today, hoping that everything would be corrrect automatically and no extra RM job for these. But that kind of re-introduced duplicates (same lib upgraded 2-3 times between releases) and now with grouping it got even more complicated. Besides, dependencies are not all alike. Some like Lucene and Jetty are much more prominent than others and sometimes deserve a more careful changelog than the one-liner. So I'm warming up to the thought of return to letting this be an RM task, backed by a script, perhaps with some LLM copywriting. Jan > 1. sep. 2026 kl. 21:27 skrev Eric Pugh <[email protected]>: > > Okay, so how do we want to handle changelog entries for these from Solrbot? > I want to draw attention to this conversation: > https://github.com/apache/solr/pull/4842#pullrequestreview-5077496282 … > > > It seems like we have a few options: > > 1) Tell Solrbot NOT to generate the changelog entry at all, since "title: > Update all non-major dependencies” isn’t useful. > > 2) Require who ever merges these to tweak the changelog to list out all the > items that are changed as part of the change. Though that might be a very > long list? > > 3) Maybe adopt documenting the dependency changes as part of the release > process? “These are the dependencies that changed between the previous > release the current one”? > > > For my part, I want to see the effort for whoever is merging these go down, > so we don’t get back into a situation where we are way out of date on > dependencies. And since Solrbot fires off 12 times a year, it means we are > only ~29 days from the next batch of Solrbot PR’s! > > Eric > > > > > > > >> On Sep 1, 2026, at 8:47 AM, Eric Pugh <[email protected]> >> wrote: >> >> It’s the first of the month, and we have 20 PR’s opened by Solrbot! >> https://github.com/apache/solr/pulls/solrbot >> >> We have six targeting branch_9x, and the rest are targeting main. Looks >> like the “Milestone” label being set to 10x is being applied, so at least >> the back porting should happen via David’s magic bak porting process. >> >> >> I think it’s kind of good news / bad news thing that it appears that the >> grouping has cut down on the number of PRs, like this one >> https://github.com/apache/solr/pull/4842 and >> https://github.com/apache/solr/pull/4845…. I can’t imagine what it was like >> before we had grouping. >> >> It looks like however we don’t have grouping on the branch_9x PR’s, with six >> different PR’s. >> >> I don’t know if 20 is going to be the average number per month, but I hope >> not! >> >> It would be great if other folks look at the PR’s and approved them. >> >> > > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
