Hi, We have a dev-doc for upgrading dependencies: https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc If something is unclear, please improve that doc.
Most SolrBot PRs are small and simple, and can be merged and backported in 2 minutes. By not adding CHANGES.txt entry we avoid lots of merge conflicst due to that one file, and as you say, all SolrBot commits are added to CHANGES during release anyway. If you do more than simply hitting the "Merge" button, feel free to add yourself as "Co-Authored-By" in the merge message. As to why not every single SolrBot PR is merged immediately, this may be due to - Long time until next solr release. To avoid upgrading the same dependency 3-4 times, just let it linger and be auto bumped until a few weeks before next release. - Some upgrades are complex and need to be coordinated with other dependencies - commons-io is barred from upgrading until a new version of Policeman tools, which adds to the time - simply lack of hands I believe a fair amount of the currently stale SolrBot PRs need extra work in terms of adding license files etc. Jan > 26. okt. 2024 kl. 19:09 skrev Gus Heck <gus.h...@gmail.com>: > > Release time is fine in my opinion. If they are automated, I wasn't > recalling it. People running unreleased code can reasonably be expected to > do their own homework, and watch commits etc. However people deciding if > they will conduct an upgrade to a new release, or how to prepare for it > will want to pay attention to some dependencies. Solrbot probably has less > use for the credit and reputation from contributing to Solr than the > developer :). > > I see a re-try checkbox on the PR's by SolrBot. I've not tried it but it > sounds like that could be used to refresh stale PR's? > > On Sat, Oct 26, 2024 at 11:46 AM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > >> 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) >>> >> > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
