On Thu, Sep 17, 2020 at 12:23 PM Matt Sicker <boa...@gmail.com> 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 <garydgreg...@gmail.com> wrote: > > > On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker <boa...@gmail.com> 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 <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> > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > -- > Matt Sicker <boa...@gmail.com> >
