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

Reply via email to