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