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 <garydgreg...@gmail.com> wrote: > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <chtom...@gmail.com> 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...@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 <boa...@gmail.com>