Re: No more dependabot
Branches have green checks on them too. Every commit does unless you push more than one at a time to a single branch (then they’re batched). This applies to both Jenkins and GH Actions. On Thu, Sep 17, 2020 at 19:39 Gary Gregory wrote: > On Thu, Sep 17, 2020 at 12:23 PM Matt Sicker wrote: > > > > > Do they show up as branches before or after the PR? If it’s before, maybe > > > we can disable the PR and just use the branches. > > > > > > > We need to keep PRs IMO: Getting a PR is the main benefit here because a > > human can verify that there is a matching green build and merge the PR from > > GitHub in one click. If the build failed then the PR might still be merged > > if after inspection the error is a random test failure and another > > "acceptable" failure like when something is wrong with a Java EA build. The > > PR can also be rebased from GitHub by adding a comment to the PR. > > > > Gary > > > > > > > On Wed, Sep 16, 2020 at 20:53 Gary Gregory > wrote: > > > > > > > On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker wrote: > > > > > > > > > > > > > > > > > > Don’t Dependabot PRs show up as branches in each git repo? > > > > > > > > > > > > > > > > Yes, which let's a build happen on that branch as a GitHub Action, > > > > > > > > assuming you have Actions enabled for your repo. > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > I noticed that > > > > > > > > > with the Dependabot config for Log4j2 at least, though perhaps > that’s a > > > > > > > > > GitBox feature. > > > > > > > > > > > > > > > > > > On Wed, Sep 16, 2020 at 19:44 Gary Gregory > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory < > > > garydgreg...@gmail.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski < > > > > gillese...@gmail.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory < > > > > garydgreg...@gmail.com> > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > >>> I think we really want the PRs, the main benefit is to have > the > > > > > > > > > > software > > > > > > > > > > > > > > > > > > > > > >>> built and tested WITH the dependency update, that is a huge > > > time > > > > > > > > > > saver. > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >> Yes, but the bot should submit the PR only when asked by a > > > human, > > > > > > > > > > > > > > > > > > > > > >> at times where it brings some value. > > > > > > > > > > > > > > > > > > > > > >> There is no value in trying all the versions of all the > plugins. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I disagree there. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Upon reflection and current experience, I want all of > Dependabot > > > > minus > > > > > > > > > > > > > > > > > > > > > > the emails. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The dependabot emails are a symptom to the real problem at hand. > We > > > > have > > > > > > > > > > quite a lot of large code bases. If the general populous was > > > > interested in > > > > > > > > > > the project, we would similarly get an overwhelming volume of > email. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don’t have a good answer here because I’m honestly trying to > > > think > > > > of > > > > > > > > > > the bot as an actual person trying to do legitimate development. If > > > we > > > > had > > > > > > > > > > a person making such a large volume of reasonable pull requests, > > > would > > > > we > > > > > > > > > > not bring them in as a committer and ask them to make direct > commits? > > > > Why > > > > > > > > > > not let dependabot loose directly on the top level branches of each > > > > project? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would say that enabling Dependabot in a repo as we've done is in > > > > > > > > > > > > > > > > > > > > fact "letting is loose": it can do anything a real GitHub user can; > > > > > > > > > > > > > > > > > > > > the boundary being that as it is not an Apache Committer, so it > > > cannot > > > > > > > > > > > > > > > > > > > > merge. I do not think we want it looser than that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then we’d get straigh
Re: No more dependabot
On Thu, Sep 17, 2020 at 12:23 PM Matt Sicker wrote: > Do they show up as branches before or after the PR? If it’s before, maybe > we can disable the PR and just use the branches. > We need to keep PRs IMO: Getting a PR is the main benefit here because a human can verify that there is a matching green build and merge the PR from GitHub in one click. If the build failed then the PR might still be merged if after inspection the error is a random test failure and another "acceptable" failure like when something is wrong with a Java EA build. The PR can also be rebased from GitHub by adding a comment to the PR. Gary > On Wed, Sep 16, 2020 at 20:53 Gary Gregory wrote: > > > On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker wrote: > > > > > > > > > > Don’t Dependabot PRs show up as branches in each git repo? > > > > > > > > Yes, which let's a build happen on that branch as a GitHub Action, > > > > assuming you have Actions enabled for your repo. > > > > > > > > Gary > > > > > > > > I noticed that > > > > > with the Dependabot config for Log4j2 at least, though perhaps that’s a > > > > > GitBox feature. > > > > > > > > > > On Wed, Sep 16, 2020 at 19:44 Gary Gregory > > wrote: > > > > > > > > > > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory < > garydgreg...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski < > > gillese...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > >> > > > > > > > > > > > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory < > > garydgreg...@gmail.com> > > > > > > a écrit : > > > > > > > > > > > > > >>> > > > > > > > > > > > > > >>> I think we really want the PRs, the main benefit is to have the > > > > > > software > > > > > > > > > > > > > >>> built and tested WITH the dependency update, that is a huge > time > > > > > > saver. > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> Yes, but the bot should submit the PR only when asked by a > human, > > > > > > > > > > > > > >> at times where it brings some value. > > > > > > > > > > > > > >> There is no value in trying all the versions of all the plugins. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I disagree there. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Upon reflection and current experience, I want all of Dependabot > > minus > > > > > > > > > > > > > > the emails. > > > > > > > > > > > > > > > > > > > > > > > > > > The dependabot emails are a symptom to the real problem at hand. We > > have > > > > > > quite a lot of large code bases. If the general populous was > > interested in > > > > > > the project, we would similarly get an overwhelming volume of email. > > > > > > > > > > > > > > > > > > > > > > > > > > I don’t have a good answer here because I’m honestly trying to > think > > of > > > > > > the bot as an actual person trying to do legitimate development. If > we > > had > > > > > > a person making such a large volume of reasonable pull requests, > would > > we > > > > > > not bring them in as a committer and ask them to make direct commits? > > Why > > > > > > not let dependabot loose directly on the top level branches of each > > project? > > > > > > > > > > > > > > > > > > > > > > > > I would say that enabling Dependabot in a repo as we've done is in > > > > > > > > > > > > fact "letting is loose": it can do anything a real GitHub user can; > > > > > > > > > > > > the boundary being that as it is not an Apache Committer, so it > cannot > > > > > > > > > > > > merge. I do not think we want it looser than that. > > > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > Then we’d get straight commit emails as opposed to this volume of > pull > > > > > > > > > > > > requests which I agree is annoying. > > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> Gilles > > > > > > > > > > > > > >> > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > - > > > > > > > > > > > > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > > > > For additional commands, e-mail: dev-h...@common
Re: No more dependabot
Do they show up as branches before or after the PR? If it’s before, maybe we can disable the PR and just use the branches. On Wed, Sep 16, 2020 at 20:53 Gary Gregory wrote: > On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker wrote: > > > > > > Don’t Dependabot PRs show up as branches in each git repo? > > > > Yes, which let's a build happen on that branch as a GitHub Action, > > assuming you have Actions enabled for your repo. > > > > Gary > > > > I noticed that > > > with the Dependabot config for Log4j2 at least, though perhaps that’s a > > > GitBox feature. > > > > > > On Wed, Sep 16, 2020 at 19:44 Gary Gregory > wrote: > > > > > > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski < > gillese...@gmail.com> > > > > wrote: > > > > > > > > > >> > > > > > > > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory < > garydgreg...@gmail.com> > > > > a écrit : > > > > > > > > > >>> > > > > > > > > > >>> I think we really want the PRs, the main benefit is to have the > > > > software > > > > > > > > > >>> built and tested WITH the dependency update, that is a huge time > > > > saver. > > > > > > > > > >> > > > > > > > > > >> Yes, but the bot should submit the PR only when asked by a human, > > > > > > > > > >> at times where it brings some value. > > > > > > > > > >> There is no value in trying all the versions of all the plugins. > > > > > > > > > > > > > > > > > > > > I disagree there. > > > > > > > > > > > > > > > > > > > > Upon reflection and current experience, I want all of Dependabot > minus > > > > > > > > > > the emails. > > > > > > > > > > > > > > > > > > The dependabot emails are a symptom to the real problem at hand. We > have > > > > quite a lot of large code bases. If the general populous was > interested in > > > > the project, we would similarly get an overwhelming volume of email. > > > > > > > > > > > > > > > > > > I don’t have a good answer here because I’m honestly trying to think > of > > > > the bot as an actual person trying to do legitimate development. If we > had > > > > a person making such a large volume of reasonable pull requests, would > we > > > > not bring them in as a committer and ask them to make direct commits? > Why > > > > not let dependabot loose directly on the top level branches of each > project? > > > > > > > > > > > > > > > > I would say that enabling Dependabot in a repo as we've done is in > > > > > > > > fact "letting is loose": it can do anything a real GitHub user can; > > > > > > > > the boundary being that as it is not an Apache Committer, so it cannot > > > > > > > > merge. I do not think we want it looser than that. > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > Then we’d get straight commit emails as opposed to this volume of pull > > > > > > > > requests which I agree is annoying. > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > >> Gilles > > > > > > > > > >> > > > > > > > > > > [...] > > > > > > > > > >> > > > > > > > > > >> > - > > > > > > > > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > -- > > > Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker
Re: No more dependabot
On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker wrote: > > Don’t Dependabot PRs show up as branches in each git repo? Yes, which let's a build happen on that branch as a GitHub Action, assuming you have Actions enabled for your repo. Gary I noticed that > with the Dependabot config for Log4j2 at least, though perhaps that’s a > GitBox feature. > > On Wed, Sep 16, 2020 at 19:44 Gary Gregory wrote: > > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins wrote: > > > > > > > > > > > > > > > > > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory > > wrote: > > > > > > > > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski > > wrote: > > > > > >> > > > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory > > a écrit : > > > > > >>> > > > > > >>> I think we really want the PRs, the main benefit is to have the > > software > > > > > >>> built and tested WITH the dependency update, that is a huge time > > saver. > > > > > >> > > > > > >> Yes, but the bot should submit the PR only when asked by a human, > > > > > >> at times where it brings some value. > > > > > >> There is no value in trying all the versions of all the plugins. > > > > > > > > > > > > I disagree there. > > > > > > > > > > > > Upon reflection and current experience, I want all of Dependabot minus > > > > > > the emails. > > > > > > > > > > The dependabot emails are a symptom to the real problem at hand. We have > > quite a lot of large code bases. If the general populous was interested in > > the project, we would similarly get an overwhelming volume of email. > > > > > > > > > > I don’t have a good answer here because I’m honestly trying to think of > > the bot as an actual person trying to do legitimate development. If we had > > a person making such a large volume of reasonable pull requests, would we > > not bring them in as a committer and ask them to make direct commits? Why > > not let dependabot loose directly on the top level branches of each project? > > > > > > > > I would say that enabling Dependabot in a repo as we've done is in > > > > fact "letting is loose": it can do anything a real GitHub user can; > > > > the boundary being that as it is not an Apache Committer, so it cannot > > > > merge. I do not think we want it looser than that. > > > > > > > > Gary > > > > > > > > Then we’d get straight commit emails as opposed to this volume of pull > > > > requests which I agree is annoying. > > > > > > > > > > Thoughts? > > > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > >> > > > > > >> Gilles > > > > > >> > > > > > > [...] > > > > > >> > > > > > >> - > > > > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > >> > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > -- > Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
Don’t Dependabot PRs show up as branches in each git repo? I noticed that with the Dependabot config for Log4j2 at least, though perhaps that’s a GitBox feature. On Wed, Sep 16, 2020 at 19:44 Gary Gregory wrote: > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins wrote: > > > > > > > > > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory > wrote: > > > > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski > wrote: > > > >> > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory > a écrit : > > > >>> > > > >>> I think we really want the PRs, the main benefit is to have the > software > > > >>> built and tested WITH the dependency update, that is a huge time > saver. > > > >> > > > >> Yes, but the bot should submit the PR only when asked by a human, > > > >> at times where it brings some value. > > > >> There is no value in trying all the versions of all the plugins. > > > > > > > > I disagree there. > > > > > > > > Upon reflection and current experience, I want all of Dependabot minus > > > > the emails. > > > > > > The dependabot emails are a symptom to the real problem at hand. We have > quite a lot of large code bases. If the general populous was interested in > the project, we would similarly get an overwhelming volume of email. > > > > > > I don’t have a good answer here because I’m honestly trying to think of > the bot as an actual person trying to do legitimate development. If we had > a person making such a large volume of reasonable pull requests, would we > not bring them in as a committer and ask them to make direct commits? Why > not let dependabot loose directly on the top level branches of each project? > > > > I would say that enabling Dependabot in a repo as we've done is in > > fact "letting is loose": it can do anything a real GitHub user can; > > the boundary being that as it is not an Apache Committer, so it cannot > > merge. I do not think we want it looser than that. > > > > Gary > > > > Then we’d get straight commit emails as opposed to this volume of pull > > requests which I agree is annoying. > > > > > > Thoughts? > > > > > > -Rob > > > > > > > > > > > > > > Gary > > > > > > > >> > > > >> Gilles > > > >> > > > > [...] > > > >> > > > >> - > > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > >> > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker
Re: No more dependabot
On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins wrote: > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory wrote: > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski > > wrote: > >> > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory a > >>> écrit : > >>> > >>> I think we really want the PRs, the main benefit is to have the software > >>> built and tested WITH the dependency update, that is a huge time saver. > >> > >> Yes, but the bot should submit the PR only when asked by a human, > >> at times where it brings some value. > >> There is no value in trying all the versions of all the plugins. > > > > I disagree there. > > > > Upon reflection and current experience, I want all of Dependabot minus > > the emails. > > The dependabot emails are a symptom to the real problem at hand. We have > quite a lot of large code bases. If the general populous was interested in > the project, we would similarly get an overwhelming volume of email. > > I don’t have a good answer here because I’m honestly trying to think of the > bot as an actual person trying to do legitimate development. If we had a > person making such a large volume of reasonable pull requests, would we not > bring them in as a committer and ask them to make direct commits? Why not let > dependabot loose directly on the top level branches of each project? I would say that enabling Dependabot in a repo as we've done is in fact "letting is loose": it can do anything a real GitHub user can; the boundary being that as it is not an Apache Committer, so it cannot merge. I do not think we want it looser than that. Gary Then we’d get straight commit emails as opposed to this volume of pull requests which I agree is annoying. > > Thoughts? > > -Rob > > > > > > Gary > > > >> > >> Gilles > >> > > [...] > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins wrote: > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory wrote: > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski > > wrote: > >> > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory a > >>> écrit : > >>> > >>> I think we really want the PRs, the main benefit is to have the software > >>> built and tested WITH the dependency update, that is a huge time saver. > >> > >> Yes, but the bot should submit the PR only when asked by a human, > >> at times where it brings some value. > >> There is no value in trying all the versions of all the plugins. > > > > I disagree there. > > > > Upon reflection and current experience, I want all of Dependabot minus > > the emails. > > The dependabot emails are a symptom to the real problem at hand. We have > quite a lot of large code bases. If the general populous was interested in > the project, we would similarly get an overwhelming volume of email. > > I don’t have a good answer here because I’m honestly trying to think of the > bot as an actual person trying to do legitimate development. If we had a > person making such a large volume of reasonable pull requests, would we not > bring them in as a committer and ask them to make direct commits? Why not let > dependabot loose directly on the top level branches of each project? Then > we’d get straight commit emails as opposed to this volume of pull requests > which I agree is annoying. I like the idea of considering Dependabot as a helpful and diligent user but it does not solve what we are struggling with here IMO and at least for me. Even if I consider Dependabot a "user", and this goes for real GitHub and Apache users, PRs from any author must be reviewed by a human before merging. For me, the PRs are key and not annoying, it's the emails that I've grown to see as noisy. I prefer to go and look at various components on GitHub from time to time and look at PRs, from Dependabot or other sources. Gary > > Thoughts? > > -Rob > > > > > > Gary > > > >> > >> Gilles > >> > > [...] > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
> On Sep 16, 2020, at 4:43 PM, Gary Gregory wrote: > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski wrote: >> >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory a >>> écrit : >>> >>> I think we really want the PRs, the main benefit is to have the software >>> built and tested WITH the dependency update, that is a huge time saver. >> >> Yes, but the bot should submit the PR only when asked by a human, >> at times where it brings some value. >> There is no value in trying all the versions of all the plugins. > > I disagree there. > > Upon reflection and current experience, I want all of Dependabot minus > the emails. The dependabot emails are a symptom to the real problem at hand. We have quite a lot of large code bases. If the general populous was interested in the project, we would similarly get an overwhelming volume of email. I don’t have a good answer here because I’m honestly trying to think of the bot as an actual person trying to do legitimate development. If we had a person making such a large volume of reasonable pull requests, would we not bring them in as a committer and ask them to make direct commits? Why not let dependabot loose directly on the top level branches of each project? Then we’d get straight commit emails as opposed to this volume of pull requests which I agree is annoying. Thoughts? -Rob > > Gary > >> >> Gilles >> > [...] >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski wrote: > > Le mer. 16 sept. 2020 à 21:09, Gary Gregory a écrit : > > > > I think we really want the PRs, the main benefit is to have the software > > built and tested WITH the dependency update, that is a huge time saver. > > Yes, but the bot should submit the PR only when asked by a human, > at times where it brings some value. > There is no value in trying all the versions of all the plugins. I disagree there. Upon reflection and current experience, I want all of Dependabot minus the emails. Gary > > Gilles > > >>> [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
Le mer. 16 sept. 2020 à 21:09, Gary Gregory a écrit : > > I think we really want the PRs, the main benefit is to have the software > built and tested WITH the dependency update, that is a huge time saver. Yes, but the bot should submit the PR only when asked by a human, at times where it brings some value. There is no value in trying all the versions of all the plugins. Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
I think we really want the PRs, the main benefit is to have the software built and tested WITH the dependency update, that is a huge time saver. Gary On Wed, Sep 16, 2020, 13:17 Ralph Goers wrote: > I am not sure that is possible since Dependabot is actually creating PRs > and GitHub sends those to the mailing list. What I heard was that they > would like to have Dependabot just send reports from time to time about > what dependencies could be changed rather than create PRs. Matt also > mentioned that if Dependabot is going to create PRs then it should also > create the corresponding Jira issues and change.xml updates if and when > projects require those. > > Ralph > > > On Sep 16, 2020, at 10:05 AM, Gary Gregory > wrote: > > > > I think the desire-complaint is how to stop Dependabot from sending > emails > > to our ML. > > > > Gary > > > > On Wed, Sep 16, 2020, 09:33 Matt Sicker wrote: > > > >> Did you know that you can configure Dependabot to ignore specific > >> dependencies and version ranges? You can also configure default > >> reviewers (see also the GitHub CODEOWNERS file which can help set up > >> default reviewers [1]). If desired, you can configure it to only make > >> PRs for security updates which would reduce them to the bare minimum. > >> If you read the (admittedly verbose) Dependabot message in the PR, it > >> has links to changelogs and whatnot for the PR it's making. Being that > >> they're PRs, I don't know of any way to hide notifications from it to > >> the dev list other than making your own filters. I think properly > >> configuring the bot would be appropriate; otherwise, it's not a useful > >> feature if it's simply ignored. > >> > >> Now if someone discovers how to automatically create Jira tickets to > >> go with the PRs, that'd be nifty. Or changelog entries. The underlying > >> code appears to be source-available, but not open source (restrictions > >> on use) [2]. > >> > >> [1]: > >> > https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners > >> [2]: https://github.com/dependabot/dependabot-core > >> > >> On Wed, 16 Sep 2020 at 07:51, Gilles Sadowski > >> wrote: > >>> > >>> Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann > >>> a écrit : > > On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski > > >> wrote: > > > Isn't what > > https://spamassassin.apache.org/ > > is about? > > Not that I am uptodate, but at least historically it hasn't. It's > mostly about blocking spam. Related, but not necessarily reusable for > the suggested purpose. > >>> > >>> I don't know the details either; I meant that, in order to block > >>> , the first step is to recognize it as such. > >>> > >>> From the above web site: > >>> ---CUT--- > >>> [...] anti-spam platform giving system administrators a filter to > >>> classify email [...] > >>> [...] scoring framework and plug-ins to integrate a wide range of > >>> advanced heuristic and statistical analysis tests on email headers and > >>> body text including text analysis [...] > >>> ---CUT--- > >>> > >>> Gilles > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > >> > >> -- > >> Matt Sicker > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: No more dependabot
I am not sure that is possible since Dependabot is actually creating PRs and GitHub sends those to the mailing list. What I heard was that they would like to have Dependabot just send reports from time to time about what dependencies could be changed rather than create PRs. Matt also mentioned that if Dependabot is going to create PRs then it should also create the corresponding Jira issues and change.xml updates if and when projects require those. Ralph > On Sep 16, 2020, at 10:05 AM, Gary Gregory wrote: > > I think the desire-complaint is how to stop Dependabot from sending emails > to our ML. > > Gary > > On Wed, Sep 16, 2020, 09:33 Matt Sicker wrote: > >> Did you know that you can configure Dependabot to ignore specific >> dependencies and version ranges? You can also configure default >> reviewers (see also the GitHub CODEOWNERS file which can help set up >> default reviewers [1]). If desired, you can configure it to only make >> PRs for security updates which would reduce them to the bare minimum. >> If you read the (admittedly verbose) Dependabot message in the PR, it >> has links to changelogs and whatnot for the PR it's making. Being that >> they're PRs, I don't know of any way to hide notifications from it to >> the dev list other than making your own filters. I think properly >> configuring the bot would be appropriate; otherwise, it's not a useful >> feature if it's simply ignored. >> >> Now if someone discovers how to automatically create Jira tickets to >> go with the PRs, that'd be nifty. Or changelog entries. The underlying >> code appears to be source-available, but not open source (restrictions >> on use) [2]. >> >> [1]: >> https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners >> [2]: https://github.com/dependabot/dependabot-core >> >> On Wed, 16 Sep 2020 at 07:51, Gilles Sadowski >> wrote: >>> >>> Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann >>> a écrit : On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski >> wrote: > Isn't what > https://spamassassin.apache.org/ > is about? Not that I am uptodate, but at least historically it hasn't. It's mostly about blocking spam. Related, but not necessarily reusable for the suggested purpose. >>> >>> I don't know the details either; I meant that, in order to block >>> , the first step is to recognize it as such. >>> >>> From the above web site: >>> ---CUT--- >>> [...] anti-spam platform giving system administrators a filter to >>> classify email [...] >>> [...] scoring framework and plug-ins to integrate a wide range of >>> advanced heuristic and statistical analysis tests on email headers and >>> body text including text analysis [...] >>> ---CUT--- >>> >>> Gilles >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> -- >> Matt Sicker >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
I think the desire-complaint is how to stop Dependabot from sending emails to our ML. Gary On Wed, Sep 16, 2020, 09:33 Matt Sicker wrote: > Did you know that you can configure Dependabot to ignore specific > dependencies and version ranges? You can also configure default > reviewers (see also the GitHub CODEOWNERS file which can help set up > default reviewers [1]). If desired, you can configure it to only make > PRs for security updates which would reduce them to the bare minimum. > If you read the (admittedly verbose) Dependabot message in the PR, it > has links to changelogs and whatnot for the PR it's making. Being that > they're PRs, I don't know of any way to hide notifications from it to > the dev list other than making your own filters. I think properly > configuring the bot would be appropriate; otherwise, it's not a useful > feature if it's simply ignored. > > Now if someone discovers how to automatically create Jira tickets to > go with the PRs, that'd be nifty. Or changelog entries. The underlying > code appears to be source-available, but not open source (restrictions > on use) [2]. > > [1]: > https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners > [2]: https://github.com/dependabot/dependabot-core > > On Wed, 16 Sep 2020 at 07:51, Gilles Sadowski > wrote: > > > > Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann > > a écrit : > > > > > > On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski > wrote: > > > > > > > Isn't what > > > >https://spamassassin.apache.org/ > > > > is about? > > > > > > Not that I am uptodate, but at least historically it hasn't. It's > > > mostly about blocking spam. Related, but not necessarily reusable for > > > the suggested purpose. > > > > I don't know the details either; I meant that, in order to block > > , the first step is to recognize it as such. > > > > From the above web site: > > ---CUT--- > > [...] anti-spam platform giving system administrators a filter to > > classify email [...] > > [...] scoring framework and plug-ins to integrate a wide range of > > advanced heuristic and statistical analysis tests on email headers and > > body text including text analysis [...] > > ---CUT--- > > > > Gilles > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- > Matt Sicker > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: No more dependabot
Did you know that you can configure Dependabot to ignore specific dependencies and version ranges? You can also configure default reviewers (see also the GitHub CODEOWNERS file which can help set up default reviewers [1]). If desired, you can configure it to only make PRs for security updates which would reduce them to the bare minimum. If you read the (admittedly verbose) Dependabot message in the PR, it has links to changelogs and whatnot for the PR it's making. Being that they're PRs, I don't know of any way to hide notifications from it to the dev list other than making your own filters. I think properly configuring the bot would be appropriate; otherwise, it's not a useful feature if it's simply ignored. Now if someone discovers how to automatically create Jira tickets to go with the PRs, that'd be nifty. Or changelog entries. The underlying code appears to be source-available, but not open source (restrictions on use) [2]. [1]: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners [2]: https://github.com/dependabot/dependabot-core On Wed, 16 Sep 2020 at 07:51, Gilles Sadowski wrote: > > Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann > a écrit : > > > > On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski > > wrote: > > > > > Isn't what > > >https://spamassassin.apache.org/ > > > is about? > > > > Not that I am uptodate, but at least historically it hasn't. It's > > mostly about blocking spam. Related, but not necessarily reusable for > > the suggested purpose. > > I don't know the details either; I meant that, in order to block > , the first step is to recognize it as such. > > From the above web site: > ---CUT--- > [...] anti-spam platform giving system administrators a filter to > classify email [...] > [...] scoring framework and plug-ins to integrate a wide range of > advanced heuristic and statistical analysis tests on email headers and > body text including text analysis [...] > ---CUT--- > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann a écrit : > > On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski wrote: > > > Isn't what > >https://spamassassin.apache.org/ > > is about? > > Not that I am uptodate, but at least historically it hasn't. It's > mostly about blocking spam. Related, but not necessarily reusable for > the suggested purpose. I don't know the details either; I meant that, in order to block , the first step is to recognize it as such. >From the above web site: ---CUT--- [...] anti-spam platform giving system administrators a filter to classify email [...] [...] scoring framework and plug-ins to integrate a wide range of advanced heuristic and statistical analysis tests on email headers and body text including text analysis [...] ---CUT--- Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski wrote: > Isn't what >https://spamassassin.apache.org/ > is about? Not that I am uptodate, but at least historically it hasn't. It's mostly about blocking spam. Related, but not necessarily reusable for the suggested purpose. Jochen --- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
Le mer. 16 sept. 2020 à 14:29, Jochen Wiedmann a écrit : > > On Wed, Sep 16, 2020 at 12:37 PM Gilles Sadowski wrote: > > > As I've already stated in the previous "discussion" (from > > where I was left with the only solution of filtering out), a lot > > of the bot-generated messages is just spam. > > IMO, it's not needed for traceability, and nobody/norobot is > > going to read it, ever; hence why accumulate it in the ML > > archive? > > Ignoring the dependabot stuff for a minute: Recognition, and analysis > of automatically generated notifications seems to me to be an > interesting subject for all ASF projects. We might start a subproject > doing just that, and hand it over to the incubator, if it turns out to > be successful? Isn't what https://spamassassin.apache.org/ is about? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Wed, Sep 16, 2020 at 12:37 PM Gilles Sadowski wrote: > As I've already stated in the previous "discussion" (from > where I was left with the only solution of filtering out), a lot > of the bot-generated messages is just spam. > IMO, it's not needed for traceability, and nobody/norobot is > going to read it, ever; hence why accumulate it in the ML > archive? Ignoring the dependabot stuff for a minute: Recognition, and analysis of automatically generated notifications seems to me to be an interesting subject for all ASF projects. We might start a subproject doing just that, and hand it over to the incubator, if it turns out to be successful? Jochen -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
2020-09-16 8:16 UTC+02:00, Jochen Wiedmann : > On Mon, Sep 14, 2020 at 2:48 PM Gary Gregory > wrote: > >> [...] >> I don't really care about >> the emails one way or another. Then why force them down onto people who did care? > > I don't need a compromise. Just wanted to trigger a discussion. The interesting functionality would be that one could "pull" a report of the possible updates, rather than being "pushed" tons of notifications at times one is not interested in them. As I've already stated in the previous "discussion" (from where I was left with the only solution of filtering out), a lot of the bot-generated messages is just spam. IMO, it's not needed for traceability, and nobody/norobot is going to read it, ever; hence why accumulate it in the ML archive? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Mon, Sep 14, 2020 at 2:48 PM Gary Gregory wrote: > - Jochen: What you do with your inbox is your business ;-) What is > the happy compromise here? Do you want a separate email list? Zero > Dependabot emails anywhere? If you feel strongly about this, please > create a [POLL] thread for what you propose. My view is that at > minimum Dependabot should still be enabled; I don't really care about > the emails one way or another. I don't need a compromise. Just wanted to trigger a discussion. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Mon, Sep 14, 2020 at 9:23 AM sebb wrote: > > On Mon, 14 Sep 2020 at 13:48, Gary Gregory wrote: > > > > - Sebb: The sooner you know something is broken, the better. For > > That is what Gump is for. > > > example: The new release of commons-net breaks commons-vfs (see my > > other email thread). It is purely coincidental that this happened at > > the time I wanted to release VFS. Still, now I don't really want to > > push through a VFS release until NET and VFS can work together again. > > I'd like help to figure out where the problem is: either it's a bug in > > NET or perhaps VFS never used NET properly since day 1. Please help > > figure it out if you are available. > > Wrong thread. I'm bringing this up more since no one replied to the thread "[VFS][NET] Failures when updating VFS from Net 3.6 to 3.7" Gary > > > - Jochen: What you do with your inbox is your business ;-) What is > > the happy compromise here? Do you want a separate email list? > > That would help. > > > Zero > > Dependabot emails anywhere? If you feel strongly about this, please > > create a [POLL] thread for what you propose. My view is that at > > minimum Dependabot should still be enabled; I don't really care about > > the emails one way or another. > > > > Gary > > > > On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > > > > > I agree. > > > > > > It would be more useful if there was a report that people could > > > consult when preparing to release a new version. > > > > > > If someone is working on a component, then they may wish to update > > > dependencies as part of that, but these mass updates distract from the > > > day-to-day changes. > > > > > > What is the use case for updating dependencies between releases? > > > > > > AFAICT the reports don't take into account Java version dependencies, > > > nor do they distinguish which updates are necessary for security > > > reasons. > > > But even if they did, I don't think there is a strong use case for > > > updating software between releases. > > > > > > Sebb. > > > > > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > > > wrote: > > > > > > > > For the record: Mails from dependabot are now being deleted > > > > automatically from my inbox. > > > > > > > > I consider this to be a failed experiment, and would like us to > > > > terminate it. > > > > > > > > Jochen > > > > > > > > > > > > > > > > -- > > > > > > > > Look, that's why there's rules, understand? So that you think before > > > > you break 'em. > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Mon, 14 Sep 2020 at 13:48, Gary Gregory wrote: > > - Sebb: The sooner you know something is broken, the better. For That is what Gump is for. > example: The new release of commons-net breaks commons-vfs (see my > other email thread). It is purely coincidental that this happened at > the time I wanted to release VFS. Still, now I don't really want to > push through a VFS release until NET and VFS can work together again. > I'd like help to figure out where the problem is: either it's a bug in > NET or perhaps VFS never used NET properly since day 1. Please help > figure it out if you are available. Wrong thread. > - Jochen: What you do with your inbox is your business ;-) What is > the happy compromise here? Do you want a separate email list? That would help. > Zero > Dependabot emails anywhere? If you feel strongly about this, please > create a [POLL] thread for what you propose. My view is that at > minimum Dependabot should still be enabled; I don't really care about > the emails one way or another. > > Gary > > On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > > > I agree. > > > > It would be more useful if there was a report that people could > > consult when preparing to release a new version. > > > > If someone is working on a component, then they may wish to update > > dependencies as part of that, but these mass updates distract from the > > day-to-day changes. > > > > What is the use case for updating dependencies between releases? > > > > AFAICT the reports don't take into account Java version dependencies, > > nor do they distinguish which updates are necessary for security > > reasons. > > But even if they did, I don't think there is a strong use case for > > updating software between releases. > > > > Sebb. > > > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > > wrote: > > > > > > For the record: Mails from dependabot are now being deleted > > > automatically from my inbox. > > > > > > I consider this to be a failed experiment, and would like us to terminate > > > it. > > > > > > Jochen > > > > > > > > > > > > -- > > > > > > Look, that's why there's rules, understand? So that you think before > > > you break 'em. > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
Le lun. 14 sept. 2020 à 14:48, Gary Gregory a écrit : > > [...] > - Jochen: What you do with your inbox is your business ;-) What is > the happy compromise here? Do you want a separate email list? Zero > Dependabot emails anywhere? If you feel strongly about this, please > create a [POLL] thread for what you propose. https://markmail.org/message/7xsy4huc22qe2gly Gilles > My view is that at > minimum Dependabot should still be enabled; I don't really care about > the emails one way or another. > > Gary > > On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > > > I agree. > > > > It would be more useful if there was a report that people could > > consult when preparing to release a new version. > > > > If someone is working on a component, then they may wish to update > > dependencies as part of that, but these mass updates distract from the > > day-to-day changes. > > > > What is the use case for updating dependencies between releases? > > > > AFAICT the reports don't take into account Java version dependencies, > > nor do they distinguish which updates are necessary for security > > reasons. > > But even if they did, I don't think there is a strong use case for > > updating software between releases. > > > > Sebb. > > > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > > wrote: > > > > > > For the record: Mails from dependabot are now being deleted > > > automatically from my inbox. > > > > > > I consider this to be a failed experiment, and would like us to terminate > > > it. > > > > > > Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
- Sebb: The sooner you know something is broken, the better. For example: The new release of commons-net breaks commons-vfs (see my other email thread). It is purely coincidental that this happened at the time I wanted to release VFS. Still, now I don't really want to push through a VFS release until NET and VFS can work together again. I'd like help to figure out where the problem is: either it's a bug in NET or perhaps VFS never used NET properly since day 1. Please help figure it out if you are available. - Jochen: What you do with your inbox is your business ;-) What is the happy compromise here? Do you want a separate email list? Zero Dependabot emails anywhere? If you feel strongly about this, please create a [POLL] thread for what you propose. My view is that at minimum Dependabot should still be enabled; I don't really care about the emails one way or another. Gary On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > I agree. > > It would be more useful if there was a report that people could > consult when preparing to release a new version. > > If someone is working on a component, then they may wish to update > dependencies as part of that, but these mass updates distract from the > day-to-day changes. > > What is the use case for updating dependencies between releases? > > AFAICT the reports don't take into account Java version dependencies, > nor do they distinguish which updates are necessary for security > reasons. > But even if they did, I don't think there is a strong use case for > updating software between releases. > > Sebb. > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > wrote: > > > > For the record: Mails from dependabot are now being deleted > > automatically from my inbox. > > > > I consider this to be a failed experiment, and would like us to terminate > > it. > > > > Jochen > > > > > > > > -- > > > > Look, that's why there's rules, understand? So that you think before > > you break 'em. > > > > -- (Terry Pratchett, Thief of Time) > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
I agree. It would be more useful if there was a report that people could consult when preparing to release a new version. If someone is working on a component, then they may wish to update dependencies as part of that, but these mass updates distract from the day-to-day changes. What is the use case for updating dependencies between releases? AFAICT the reports don't take into account Java version dependencies, nor do they distinguish which updates are necessary for security reasons. But even if they did, I don't think there is a strong use case for updating software between releases. Sebb. On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann wrote: > > For the record: Mails from dependabot are now being deleted > automatically from my inbox. > > I consider this to be a failed experiment, and would like us to terminate it. > > Jochen > > > > -- > > Look, that's why there's rules, understand? So that you think before > you break 'em. > > -- (Terry Pratchett, Thief of Time) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
