[GitHub] [commons-io] coveralls commented on pull request #153: Bump junit-jupiter from 5.6.2 to 5.7.0

[GitBox <gi...@apache.org>]

coveralls commented on pull request #153:
URL: https://github.com/apache/commons-io/pull/153#issuecomment-691840428


   
   [![Coverage Status](https://coveralls.io/builds/33431908/badge)](https://coveralls.io/builds/33431908)
   
   Coverage decreased (-0.06%) to 89.429% when pulling **5d40cebee80e660917434db2b963bab3704216ca on dependabot/maven/org.junit.jupiter-junit-jupiter-5.7.0** into **cdf779422d47637ead33e094ae8f971de1c395f6 on master**.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
> > On Sep 16, 2020, at 4:43 PM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
> >>
> >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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? 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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Matt Sicker <bo...@gmail.com>]

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 <ga...@gmail.com> wrote:

> On Thu, Sep 17, 2020 at 12:23 PM Matt Sicker <bo...@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 <ga...@gmail.com>
> wrote:
>
> >
>
> > > On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker <bo...@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 <ga...@gmail.com>
>
> > > wrote:
>
> > >
>
> > > >
>
> > >
>
> > > > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com>
>
> > > wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory <
>
> > garydgregory@gmail.com>
>
> > >
>
> > > > > wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <
>
> > > gilleseran@gmail.com>
>
> > >
>
> > > > > wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >>
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <
>
> > > garydgregory@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-unsubscribe@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >> For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >>
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >
>
> > > ---------------------------------------------------------------------
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > ---------------------------------------------------------------------
>
> > >
>
> > > > >
>
> > >
>
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
> ---------------------------------------------------------------------
>
> > >
>
> > > > >
>
> > >
>
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > --
>
> > >
>
> > > > Matt Sicker <bo...@gmail.com>
>
> > >
>
> > >
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > >
>
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > Matt Sicker <bo...@gmail.com>
>
> >
>
> --
Matt Sicker <bo...@gmail.com>

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

On Thu, Sep 17, 2020 at 12:23 PM Matt Sicker <bo...@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 <ga...@gmail.com> wrote:
>
> > On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker <bo...@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 <ga...@gmail.com>
> > wrote:
> >
> > >
> >
> > > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com>
> > wrote:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory <
> garydgregory@gmail.com>
> >
> > > > wrote:
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <
> > gilleseran@gmail.com>
> >
> > > > wrote:
> >
> > > >
> >
> > > > > >>
> >
> > > >
> >
> > > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <
> > garydgregory@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-unsubscribe@commons.apache.org
> >
> > > >
> >
> > > > > >> For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > >
> >
> > > > > >>
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> > ---------------------------------------------------------------------
> >
> > > >
> >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > >
> >
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> ---------------------------------------------------------------------
> >
> > > >
> >
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > >
> >
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > ---------------------------------------------------------------------
> >
> > > >
> >
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > >
> >
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > Matt Sicker <bo...@gmail.com>
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> > --
> Matt Sicker <bo...@gmail.com>
>

Re: No more dependabot

[Matt Sicker <bo...@gmail.com>]

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 <ga...@gmail.com> wrote:

> On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker <bo...@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 <ga...@gmail.com>
> wrote:
>
> >
>
> > > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com>
> wrote:
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory <ga...@gmail.com>
>
> > > wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <
> gilleseran@gmail.com>
>
> > > wrote:
>
> > >
>
> > > > >>
>
> > >
>
> > > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <
> garydgregory@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-unsubscribe@commons.apache.org
>
> > >
>
> > > > >> For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > > >>
>
> > >
>
> > > > >
>
> > >
>
> > > > >
> ---------------------------------------------------------------------
>
> > >
>
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > > >
>
> > >
>
> > > >
>
> > >
>
> > > > ---------------------------------------------------------------------
>
> > >
>
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > > >
>
> > >
>
> > >
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > >
>
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > >
>
> > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > Matt Sicker <bo...@gmail.com>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> --
Matt Sicker <bo...@gmail.com>

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

On Wed, Sep 16, 2020 at 8:53 PM Matt Sicker <bo...@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 <ga...@gmail.com> wrote:
>
> > On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com> wrote:
> >
> > >
> >
> > >
> >
> > >
> >
> > > > On Sep 16, 2020, at 4:43 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> > > >
> >
> > > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> > > >>
> >
> > > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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-unsubscribe@commons.apache.org
> >
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > >>
> >
> > > >
> >
> > > > ---------------------------------------------------------------------
> >
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > >
> >
> > >
> >
> > > ---------------------------------------------------------------------
> >
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> > --
> Matt Sicker <bo...@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Matt Sicker <bo...@gmail.com>]

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 <ga...@gmail.com> wrote:

> On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com> wrote:
>
> >
>
> >
>
> >
>
> > > On Sep 16, 2020, at 4:43 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
> > >
>
> > > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > >>
>
> > >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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-unsubscribe@commons.apache.org
>
> > >> For additional commands, e-mail: dev-help@commons.apache.org
>
> > >>
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > For additional commands, e-mail: dev-help@commons.apache.org
>
> >
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> --
Matt Sicker <bo...@gmail.com>

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

On Wed, Sep 16, 2020 at 7:10 PM Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
> > On Sep 16, 2020, at 4:43 PM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
> >>
> >>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Rob Tompkins <ch...@gmail.com>]

> On Sep 16, 2020, at 4:43 PM, Gary Gregory <ga...@gmail.com> wrote:
> 
> On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
>> 
>>> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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? 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

On Wed, Sep 16, 2020 at 4:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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.

Gary

>
> Gilles
>
> >>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gilles Sadowski <gi...@gmail.com>]

Le mer. 16 sept. 2020 à 21:09, Gary Gregory <ga...@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.

Gilles

>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

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 <ra...@dslextreme.com> 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 <ga...@gmail.com>
> 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 <bo...@gmail.com> 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 <gi...@gmail.com>
> >> wrote:
> >>>
> >>> Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
> >>> <jo...@gmail.com> a écrit :
> >>>>
> >>>> On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski <gilleseran@gmail.com
> >
> >> 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
> >>> <unsolicited contents>, 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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: No more dependabot

[Ralph Goers <ra...@dslextreme.com>]

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 <ga...@gmail.com> 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 <bo...@gmail.com> 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 <gi...@gmail.com>
>> wrote:
>>> 
>>> Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
>>> <jo...@gmail.com> a écrit :
>>>> 
>>>> On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski <gi...@gmail.com>
>> 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
>>> <unsolicited contents>, 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> --
>> Matt Sicker <bo...@gmail.com>
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

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 <bo...@gmail.com> 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 <gi...@gmail.com>
> wrote:
> >
> > Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
> > <jo...@gmail.com> a écrit :
> > >
> > > On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski <gi...@gmail.com>
> 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
> > <unsolicited contents>, 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: No more dependabot

[Matt Sicker <bo...@gmail.com>]

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 <gi...@gmail.com> wrote:
>
> Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
> <jo...@gmail.com> a écrit :
> >
> > On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski <gi...@gmail.com> 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
> <unsolicited contents>, 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


-- 
Matt Sicker <bo...@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gilles Sadowski <gi...@gmail.com>]

Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
<jo...@gmail.com> a écrit :
>
> On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski <gi...@gmail.com> 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
<unsolicited contents>, 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Jochen Wiedmann <jo...@gmail.com>]

On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski <gi...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gilles Sadowski <gi...@gmail.com>]

Le mer. 16 sept. 2020 à 14:29, Jochen Wiedmann
<jo...@gmail.com> a écrit :
>
> On Wed, Sep 16, 2020 at 12:37 PM Gilles Sadowski <gi...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Jochen Wiedmann <jo...@gmail.com>]

On Wed, Sep 16, 2020 at 12:37 PM Gilles Sadowski <gi...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gilles Sadowski <gi...@gmail.com>]

2020-09-16 8:16 UTC+02:00, Jochen Wiedmann <jo...@gmail.com>:
> On Mon, Sep 14, 2020 at 2:48 PM Gary Gregory <ga...@gmail.com>
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Jochen Wiedmann <jo...@gmail.com>]

On Mon, Sep 14, 2020 at 2:48 PM Gary Gregory <ga...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gilles Sadowski <gi...@gmail.com>]

Le lun. 14 sept. 2020 à 14:48, Gary Gregory <ga...@gmail.com> 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 <se...@gmail.com> 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 <jo...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

On Mon, Sep 14, 2020 at 9:23 AM sebb <se...@gmail.com> wrote:
>
> On Mon, 14 Sep 2020 at 13:48, Gary Gregory <ga...@gmail.com> 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 <se...@gmail.com> 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 <jo...@gmail.com> 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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[sebb <se...@gmail.com>]

On Mon, 14 Sep 2020 at 13:48, Gary Gregory <ga...@gmail.com> 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 <se...@gmail.com> 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 <jo...@gmail.com> 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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[Gary Gregory <ga...@gmail.com>]

- 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 <se...@gmail.com> 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 <jo...@gmail.com> 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: No more dependabot

[sebb <se...@gmail.com>]

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 <jo...@gmail.com> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

No more dependabot

[Jochen Wiedmann <jo...@gmail.com>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org