>From what I understood, entries in CHANGES.txt are automatically added during release processes, so no actions are necessary from the developer's point of view when merging the Solrbot PRs.
If I get you right Gus, you'd like to see at least these entries earlier, and the changes should contain the developer that addressed and merged solrbot's PR, instead of solrbot. Is that correct? If that's the case, I may agree with you, but there is one "issue" I want to understand before adding one more action to the process. We have PRs from Solrbot that are more than 6 months old. This means that the process of updating dependencies is complex, time consuming, error-prone or no one wants to take responsibility. At least that's what my previous experience with updates in other projects was. So I believe that adding one more step into the process may worsen the developer experience of addressing dependency updates. And since these updates often address CVEs and other functionality issues, I see this as a crucial part of maintenance. I am trying to understand the reasons for these specific PRs becoming stale, so that we can take actions and improve this part. If anyone has any experiences or information please share them. On Sat, Oct 26, 2024 at 4:45 PM Gus Heck <gus.h...@gmail.com> wrote: > Changes in our dependencies ought to be tracked somewhere more digestible > than VCS. Users who use our test framework or have repositories containing > custom code intended to run inside of solr will care about changes in deps > for both solrj, and core, and whatever components. CHANGES.txt isn't great > either, but it's better than nothing. (i.e. > > https://solr.apache.org/docs/9_7_0/changes/Changes.html#v9.7.0.dependency_upgrades > ) > Ideally an automated dependency upgrade report could exist, but I'm not > sure what tool might exist for that. > > So I think a Changes.txt entry can be added as a follow on in the case of a > direct merge. Simply saying something like we have in the past, just the > library and the committer, and the PR/JIRA as applicable. Solrbot's > involvement is irrelevant to users, so something like: SOLR-15609: Upgrade > log4j to 2.14.1 (hossman) > > On Thu, Oct 24, 2024 at 10:16 AM Christos Malliaridis < > malliari...@apache.org> wrote: > > > I got a few questions before interacting with the Solrbot PRs, because I > > haven't done that before. > > > > - When are the CHANGES entries added, and when not? Is it just "if > Solrbot > > created the PR, then it will be added automatically during next release"? > > - In case no additional actions are necessary, would I simply merge the > PR > > via GitHub and look into backporting the changes as usual? > > - In case changes are necesasry, would I simply pick up from where > Solrbot > > left off and continue working on the PR? > > - Should any dependency that requires JDK > 11 be backported to 9x? > > - And if not, should any older version of the dependency that supports > JDK > > 11 but is newer to the one in use be "backported" instead? Like minor and > > patch versions. > > > > I'd be happy to tackle the PRs as soon as possible. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
