That’s probably a question for asf legal On Thu, Apr 18, 2024 at 5:36 PM Eric Pugh <ep...@opensourceconnections.com> wrote:
> Thanks for the work that has been done on some of these. > > I actually just ran through the process of updating commons-cli based on > what SolrBot provided. I *did* have to update a Java class, and I did > regenerate the licenses, and that was about it… > > Which made me wonder.. If SolrBot opens a dependency upgrade, and > recommit and the tests pass, could we have it just commit automatically the > update? > > I looked at one that I constantly see, the update to the awssdk: > https://github.com/apache/solr/pull/2056. The tests all pass, and it > appears all I need to do to make precommit happy is drop in some new > licenses. Other than that, I believe that I could merge that PR, and I > wouldn’t need to do any other steps…. So, if there were no new license and > precommit had passed, couldn’t SolrBot merge it for us? > > Basically, do we actually need a human in the loop on this when at least > this human, me, wouldn’t really be doing anything else if all the checks > passed…. > > > On Apr 9, 2024, at 8:01 AM, Eric Pugh <ep...@opensourceconnections.com> > wrote: > > > > The update that I see a lot is for the software.amazon.awssdk and > com.google.cloud packages…. I checked renovate.json and they should only > happen once a month. > > > > I just checked and there has been an update today, yesterday, and the > day before for the software.amazon.awssdk package. > > > > Looks like they all go to https://github.com/apache/solr/pull/2056 > however. Is this because once it opens the PR, it is just updating the PR > as needed? > > > > How can we get a smoother workflow? The constant updates are noisy, > and now I think they are just ignored…! I saw that Kevin approved this > back in November 2023. Do we want to be more on top of these and merge as > they go? > > > > And maybe for these frequently changing ones, maybe move to a quarterly > schedule? Or, do we add it to the release manager process, though I know > that approach was discussed and then viewed as too burdensome for the RM. > > > > > > > > Eric > > > > > > > > > > > > _______________________ > > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. > > > > _______________________ > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. > >