Re: Re: can we get rid of dependabot?

[Eric Bresie]

Noticed on recent dependabot PR the below being added to the PR.

Would using any of these options (i.e. like @dependabot close which prevent
some of the repeats notifications) help?

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

   - @dependabot rebase will rebase this PR
   - @dependabot recreate will recreate this PR, overwriting any edits that
   have been made to it
   - @dependabot merge will merge this PR after your CI passes on it
   - @dependabot squash and merge will squash and merge this PR after your
   CI passes on it
   - @dependabot cancel merge will cancel a previously requested merge and
   block automerging
   - @dependabot reopen will reopen this PR if it is closed
   - *@dependabot close will close this PR and stop Dependabot recreating
   it. You can achieve the same result by closing it manually*
   - @dependabot ignore this major version will close this PR and stop
   Dependabot creating any more for this major version (unless you reopen the
   PR or upgrade to it yourself)
   - @dependabot ignore this minor version will close this PR and stop
   Dependabot creating any more for this minor version (unless you reopen the
   PR or upgrade to it yourself)
   - @dependabot ignore this dependency will close this PR and stop
   Dependabot creating any more for this dependency (unless you reopen the PR
   or upgrade to it yourself)


On Sun, Jan 2, 2022 at 9:36 AM Eric Bresie  wrote:

> Late to the discussion but I think what is being said and with a few
> follow up questions is…
>
> The problem discussed is when a dependabot check occurs following a
> commit, it highlights out of date dependencies (possibly security related)
> which notifies folks via an automated email sent to multiple mailing list
> with the frequency of such resulting in giving mailing list overwhelmed by
> the frequent checks for dependencies updates.  Is this correct?
>
> It sounds like what is being proposed (and in work) is for the dependabot
> configuration to change the frequency, trigger, and/or destination for the
> emails…is this correct?
>
> From dependency perspective, is the behavior, it notifies for the need for
> an update or does it create an automated updated via a generates “PR” to
> address direct and indirect dependency updates?  Assume for PR case a
> “person in the loop” is still required to review and merge in the PR…right?
>
> From a higher level, is it correct to say, this attempts to reduce the
> risk of security or out of date dependency issues by automating the version
> dependencies checks/updates in a given build and reduce the amount of time
> and manual involvement to reduce security (and other dependency) updates?
>
> I hope this would be considered sooner in the pipeline and maybe for
> another thread, but…if someone has an upstream dependency of some type, and
> a “bad actors” corrupts and updates a given upstream dependency, would this
> potentially “automate the spread” of a “bad actors” dependency update?
> Assume the “person in the loop” would hopefully reduce the risk but just
> thinking worse case scenario here.
>
>
> Eric Bresie
> ebre...@gmail.com
>
> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins 
> wrote:
> I believe that we already have begun to do this. -Rob
>
> On Dec 30, 2021, at 6:16 PM, sebb  wrote:
>
> Those of you who want to keep the robot, please use the instructions
> to reduce the spam.
>
> On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  wrote:
>
>
>
> On Dec 30, 2021, at 5:50 PM, Matt Sicker  wrote:
>
>
> There are tons of options to configure. The defaults are handy for
> smaller projects, but they are clearly spammy for larger ones like this.
>
>
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> <
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
>
>
>
> +1
>
> --
> Matt Sicker
>
> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
>
>
>
> On Dec 30, 2021, at 5:37 PM, sebb  mailto:seb...@gmail.com >> wrote:
>
>
> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  mailto:chtom...@gmail.com >> wrote:
>
>
> Guys. The fundamental argument underpinng all this is whether it’s better
> to have robot eyes on the code and human eyes on the code. Stop arguing one
> side or the other. We need to find a way to do both successfully.
>
>
> The issue is *not* about robot or no robot.
>
> It is about this particular robot that causes so much noise.
>
>
> Yes! That’s right so we need to figure out how to use the robot correctly!
>
>
>
>
> On Dec 29, 2021, at 1:57 PM, Phil Steitz  mailto:phil.ste...@gmail.com >> wrote:
>
>
> 
>
> On 12/29/21 8:43 AM, sebb wrote:
>
> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  mailto:garydgreg...@gmail.com >> wrote:
>
> On Wed, Dec 29, 2021 at 9:42 AM sebb  mailto:seb...@gmail.com >> wrot

Re: Re: can we get rid of dependabot?

[Xeno Amess]

IMO it is the dependency's developer's duti to keep their private key safe, and 
oss 's duty to keep the uploaded dependency stored and delivered safe.

If you really think to apply zero trust in this way, maybe we shall also think 
git, github, maven, jdk, system,all of them have possibility to corrupt the 
artiface.


XenoAmess

From: Eric Bresie 
Sent: Sunday, January 2, 2022 11:36:18 PM
To: dev@commons.apache.org 
Subject: Re: Re: can we get rid of dependabot?

Late to the discussion but I think what is being said and with a few follow up 
questions is…

The problem discussed is when a dependabot check occurs following a commit, it 
highlights out of date dependencies (possibly security related) which notifies 
folks via an automated email sent to multiple mailing list with the frequency 
of such resulting in giving mailing list overwhelmed by the frequent checks for 
dependencies updates. Is this correct?

It sounds like what is being proposed (and in work) is for the dependabot 
configuration to change the frequency, trigger, and/or destination for the 
emails…is this correct?

From dependency perspective, is the behavior, it notifies for the need for an 
update or does it create an automated updated via a generates “PR” to address 
direct and indirect dependency updates? Assume for PR case a “person in the 
loop” is still required to review and merge in the PR…right?

From a higher level, is it correct to say, this attempts to reduce the risk of 
security or out of date dependency issues by automating the version 
dependencies checks/updates in a given build and reduce the amount of time and 
manual involvement to reduce security (and other dependency) updates?

I hope this would be considered sooner in the pipeline and maybe for another 
thread, but…if someone has an upstream dependency of some type, and a “bad 
actors” corrupts and updates a given upstream dependency, would this 
potentially “automate the spread” of a “bad actors” dependency update? Assume 
the “person in the loop” would hopefully reduce the risk but just thinking 
worse case scenario here.

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins  (mailto:chtom...@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb  > (mailto:seb...@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  > > (mailto:chtom...@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker  > > > > (mailto:boa...@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for 
> > > > smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> > > >  
> > > > <https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb  > > > > > > (mailto:seb...@gmail.com) <mailto:seb...@gmail.com>> wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com) <mailto:chtom...@gmail.com>> wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether 
> > > > > > > it’s better to have robot eyes on the code and human eyes on the 
> > > > > > > code. Stop arguing one side or the other. We need to find a way 
> > > > > > > to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot 
> > > > > correctly!
> > > &g

Re: Re: can we get rid of dependabot?

[Eric Bresie]

Late to the discussion but I think what is being said and with a few follow up 
questions is…

The problem discussed is when a dependabot check occurs following a commit, it 
highlights out of date dependencies (possibly security related) which notifies 
folks via an automated email sent to multiple mailing list with the frequency 
of such resulting in giving mailing list overwhelmed by the frequent checks for 
dependencies updates. Is this correct?

It sounds like what is being proposed (and in work) is for the dependabot 
configuration to change the frequency, trigger, and/or destination for the 
emails…is this correct?

From dependency perspective, is the behavior, it notifies for the need for an 
update or does it create an automated updated via a generates “PR” to address 
direct and indirect dependency updates? Assume for PR case a “person in the 
loop” is still required to review and merge in the PR…right?

From a higher level, is it correct to say, this attempts to reduce the risk of 
security or out of date dependency issues by automating the version 
dependencies checks/updates in a given build and reduce the amount of time and 
manual involvement to reduce security (and other dependency) updates?

I hope this would be considered sooner in the pipeline and maybe for another 
thread, but…if someone has an upstream dependency of some type, and a “bad 
actors” corrupts and updates a given upstream dependency, would this 
potentially “automate the spread” of a “bad actors” dependency update? Assume 
the “person in the loop” would hopefully reduce the risk but just thinking 
worse case scenario here.

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins  (mailto:chtom...@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb  > (mailto:seb...@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  > > (mailto:chtom...@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker  > > > > (mailto:boa...@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for 
> > > > smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> > > >  
> > > > 
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb  > > > > > > (mailto:seb...@gmail.com) > wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com) > wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether 
> > > > > > > it’s better to have robot eyes on the code and human eyes on the 
> > > > > > > code. Stop arguing one side or the other. We need to find a way 
> > > > > > > to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot 
> > > > > correctly!
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > On Dec 29, 2021, at 1:57 PM, Phil Steitz 
> > > > > > > > > mailto:phil.ste...@gmail.com) 
> > > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > > On 12/29/21 8:43 AM, sebb wrote:
> > > > > > > > > > On Wed, 29 Dec 2021 at 14:53, Gary Gregory 
> > > > > > > > > > mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > wrote:
> > > > > > > > > > > On Wed, Dec 29, 2021 at 9:42 AM sebb  > > > > > > > > > > (mailto:seb...@gmail.com) > 
> > > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Wed, 29 Dec 2021 at 14:18, Gary Gregory 
> > > > > > > > > > > mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > On Wed, Dec 29, 2021 at 9:07 AM sebb  > > > > > > > > > > > (mailto:seb...@gmail.com) > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> > > > > > > > > > > > >  > > > > > > > > > > > > (mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > > > 

Re: can we get rid of dependabot?

[Rob Tompkins]

I believe that we already have begun to do this. -Rob

> On Dec 30, 2021, at 6:16 PM, sebb  wrote:
> 
> Those of you who want to keep the robot, please use the instructions
> to reduce the spam.
> 
>> On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  wrote:
>> 
>> 
>> 
 On Dec 30, 2021, at 5:50 PM, Matt Sicker  wrote:
>>> 
>>> There are tons of options to configure. The defaults are handy for smaller 
>>> projects, but they are clearly spammy for larger ones like this.
>>> 
>>> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
>>>  
>>> 
>>> 
>> 
>> +1
>> 
>>> --
>>> Matt Sicker
>>> 
> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
> 
> 
> 
>> On Dec 30, 2021, at 5:37 PM, sebb > > wrote:
> 
> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  > wrote:
>> 
>> Guys. The fundamental argument underpinng all this is whether it’s 
>> better to have robot eyes on the code and human eyes on the code. Stop 
>> arguing one side or the other. We need to find a way to do both 
>> successfully.
> 
> The issue is *not* about robot or no robot.
> 
> It is about this particular robot that causes so much noise.
 
 Yes! That’s right so we need to figure out how to use the robot correctly!
 
> 
>> 
>> 
 On Dec 29, 2021, at 1:57 PM, Phil Steitz >>> > wrote:
>>> 
>>> 
>>> 
 On 12/29/21 8:43 AM, sebb wrote:
> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  > wrote:
>> On Wed, Dec 29, 2021 at 9:42 AM sebb > > wrote:
> 
>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory > > wrote:
>>> On Wed, Dec 29, 2021 at 9:07 AM sebb >> > wrote:
>>> 
 On Wed, 29 Dec 2021 at 13:54, Gary Gregory >>> >
>> wrote:
> One critical feature is that dependabot does all the builds for 
> you
>> on
> GitHub Actions, this is an enormous time and resource saver!
 Not at all.
 Just the reverse.
 
 It does NOT save resources, because it runs builds for updates that
 are not necessary at that point in time (or ever, in some cases).
 
 Nor does it same time, because the the noise that it generates.
 
 
 Please stop pretending that Dependabot does things it does not (and
 likely cannot) do.
 
>>> Oh, boy, Sebb, it feels like you are purposely misunderstanding my 
>>> POV.
>>> It's as simple as I stated:
>>> 
>>> If Dependabot detects that a new version of a dependency is 
>>> available,
>>> creates a branch, runs a build, tells me the result and I have a PR 
>>> I can
>>> merge, *that is all work and time *I* do not have to do manually! 
>>> Why is
>>> that so hard to understand?*
>> Of course I understand that.
>> 
> Phew! :-)
> 
>> However, just because a new version is available does NOT mean that 
>> it
>> has to be updated there and then.
>> Sometimes it never needs to be updated.
>> 
> You can't know if you need to make a decision unless someone asks you 
> to
> make it. I don't know out of thin air that a new version is available.
 You can be pro-active and do a dependency check yourself.
 And you can look out for security bulletins.
 
 That's what we used to do.
 
>> Changes to dependencies occur much more frequently than component 
>> releases.
>> So often there will be several mails for the same dependency.
>> 
>> In the past, the approach was to check for new (and useful) updates
>> shortly before a release.
>> 
> That must have been before my time and it seems like a horrible idea: 
> The
> software is stable after a few months of activity and it's time to 
> make a
> release, so the day before a release, you change all the 
> dependencies, and
> cross your fingers? Yikes!
 That is NOT what I said.
 
 Obviously one would start working on version updates some time before
 the release.
 Days or weeks rather than months or years.
 
>> Generally all the versions would be updated at the s

Re: can we get rid of dependabot?

[sebb]

Those of you who want to keep the robot, please use the instructions
to reduce the spam.

On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  wrote:
>
>
>
> > On Dec 30, 2021, at 5:50 PM, Matt Sicker  wrote:
> >
> > There are tons of options to configure. The defaults are handy for smaller 
> > projects, but they are clearly spammy for larger ones like this.
> >
> > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> >  
> > 
> >
>
> +1
>
> > --
> > Matt Sicker
> >
> >>> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
> >>>
> >>>
> >>>
>  On Dec 30, 2021, at 5:37 PM, sebb   > wrote:
> >>>
> >>> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  >>> > wrote:
> 
>  Guys. The fundamental argument underpinng all this is whether it’s 
>  better to have robot eyes on the code and human eyes on the code. Stop 
>  arguing one side or the other. We need to find a way to do both 
>  successfully.
> >>>
> >>> The issue is *not* about robot or no robot.
> >>>
> >>> It is about this particular robot that causes so much noise.
> >>
> >> Yes! That’s right so we need to figure out how to use the robot correctly!
> >>
> >>>
> 
> 
> >> On Dec 29, 2021, at 1:57 PM, Phil Steitz  >> > wrote:
> >
> > 
> >
> >> On 12/29/21 8:43 AM, sebb wrote:
> >>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  >>> > wrote:
>  On Wed, Dec 29, 2021 at 9:42 AM sebb   > wrote:
> >>>
>  On Wed, 29 Dec 2021 at 14:18, Gary Gregory   > wrote:
> > On Wed, Dec 29, 2021 at 9:07 AM sebb  > > wrote:
> >
> >> On Wed, 29 Dec 2021 at 13:54, Gary Gregory  >> >
>  wrote:
> >>> One critical feature is that dependabot does all the builds for 
> >>> you
>  on
> >>> GitHub Actions, this is an enormous time and resource saver!
> >> Not at all.
> >> Just the reverse.
> >>
> >> It does NOT save resources, because it runs builds for updates that
> >> are not necessary at that point in time (or ever, in some cases).
> >>
> >> Nor does it same time, because the the noise that it generates.
> >>
> >>
> >> Please stop pretending that Dependabot does things it does not (and
> >> likely cannot) do.
> >>
> > Oh, boy, Sebb, it feels like you are purposely misunderstanding my 
> > POV.
> > It's as simple as I stated:
> >
> > If Dependabot detects that a new version of a dependency is 
> > available,
> > creates a branch, runs a build, tells me the result and I have a PR 
> > I can
> > merge, *that is all work and time *I* do not have to do manually! 
> > Why is
> > that so hard to understand?*
>  Of course I understand that.
> 
> >>> Phew! :-)
> >>>
>  However, just because a new version is available does NOT mean that 
>  it
>  has to be updated there and then.
>  Sometimes it never needs to be updated.
> 
> >>> You can't know if you need to make a decision unless someone asks you 
> >>> to
> >>> make it. I don't know out of thin air that a new version is available.
> >> You can be pro-active and do a dependency check yourself.
> >> And you can look out for security bulletins.
> >>
> >> That's what we used to do.
> >>
>  Changes to dependencies occur much more frequently than component 
>  releases.
>  So often there will be several mails for the same dependency.
> 
>  In the past, the approach was to check for new (and useful) updates
>  shortly before a release.
> 
> >>> That must have been before my time and it seems like a horrible idea: 
> >>> The
> >>> software is stable after a few months of activity and it's time to 
> >>> make a
> >>> release, so the day before a release, you change all the 
> >>> dependencies, and
> >>> cross your fingers? Yikes!
> >> That is NOT what I said.
> >>
> >> Obviously one would start working on version updates some time before
> >> the release.
> >> Days or weeks rather than months or years.
> >>
>  Generally all the versions would be updated at the same time, instead
>  of individually.
> 
> >>> Not here, if update 10 dependencies and a build fails, then what? I 
> >>> go back
> >>>

Re: can we get rid of dependabot?

[Rob Tompkins]

> On Dec 30, 2021, at 5:50 PM, Matt Sicker  wrote:
> 
> There are tons of options to configure. The defaults are handy for smaller 
> projects, but they are clearly spammy for larger ones like this.
> 
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
>  
> 
> 

+1

> --
> Matt Sicker
> 
>>> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
>>> 
>>> 
>>> 
 On Dec 30, 2021, at 5:37 PM, sebb >>> > wrote:
>>> 
>>> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins >> > wrote:
 
 Guys. The fundamental argument underpinng all this is whether it’s better 
 to have robot eyes on the code and human eyes on the code. Stop arguing 
 one side or the other. We need to find a way to do both successfully.
>>> 
>>> The issue is *not* about robot or no robot.
>>> 
>>> It is about this particular robot that causes so much noise.
>> 
>> Yes! That’s right so we need to figure out how to use the robot correctly!
>> 
>>> 
 
 
>> On Dec 29, 2021, at 1:57 PM, Phil Steitz > > wrote:
> 
> 
> 
>> On 12/29/21 8:43 AM, sebb wrote:
>>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory >> > wrote:
 On Wed, Dec 29, 2021 at 9:42 AM sebb >>> > wrote:
>>> 
 On Wed, 29 Dec 2021 at 14:18, Gary Gregory >>> > wrote:
> On Wed, Dec 29, 2021 at 9:07 AM sebb  > wrote:
> 
>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory > >
 wrote:
>>> One critical feature is that dependabot does all the builds for you
 on
>>> GitHub Actions, this is an enormous time and resource saver!
>> Not at all.
>> Just the reverse.
>> 
>> It does NOT save resources, because it runs builds for updates that
>> are not necessary at that point in time (or ever, in some cases).
>> 
>> Nor does it same time, because the the noise that it generates.
>> 
>> 
>> Please stop pretending that Dependabot does things it does not (and
>> likely cannot) do.
>> 
> Oh, boy, Sebb, it feels like you are purposely misunderstanding my 
> POV.
> It's as simple as I stated:
> 
> If Dependabot detects that a new version of a dependency is available,
> creates a branch, runs a build, tells me the result and I have a PR I 
> can
> merge, *that is all work and time *I* do not have to do manually! Why 
> is
> that so hard to understand?*
 Of course I understand that.
 
>>> Phew! :-)
>>> 
 However, just because a new version is available does NOT mean that it
 has to be updated there and then.
 Sometimes it never needs to be updated.
 
>>> You can't know if you need to make a decision unless someone asks you to
>>> make it. I don't know out of thin air that a new version is available.
>> You can be pro-active and do a dependency check yourself.
>> And you can look out for security bulletins.
>> 
>> That's what we used to do.
>> 
 Changes to dependencies occur much more frequently than component 
 releases.
 So often there will be several mails for the same dependency.
 
 In the past, the approach was to check for new (and useful) updates
 shortly before a release.
 
>>> That must have been before my time and it seems like a horrible idea: 
>>> The
>>> software is stable after a few months of activity and it's time to make 
>>> a
>>> release, so the day before a release, you change all the dependencies, 
>>> and
>>> cross your fingers? Yikes!
>> That is NOT what I said.
>> 
>> Obviously one would start working on version updates some time before
>> the release.
>> Days or weeks rather than months or years.
>> 
 Generally all the versions would be updated at the same time, instead
 of individually.
 
>>> Not here, if update 10 dependencies and a build fails, then what? I go 
>>> back
>>> to square one and update each, one at a time, until I find the culprit,
>>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
>>> for components like VFS, Configuration, and others.
>> Well yes, but how likely is there to be a failure in such circumstances?
>> 
>> If the build does not fail, you have saved the noise from at least 9
>> updates which are gene

Re: can we get rid of dependabot?

[Matt Sicker]

There are tons of options to configure. The defaults are handy for smaller 
projects, but they are clearly spammy for larger ones like this.

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
 


--
Matt Sicker

> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
> 
> 
> 
>> On Dec 30, 2021, at 5:37 PM, sebb > > wrote:
>> 
>> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins > > wrote:
>>> 
>>> Guys. The fundamental argument underpinng all this is whether it’s better 
>>> to have robot eyes on the code and human eyes on the code. Stop arguing one 
>>> side or the other. We need to find a way to do both successfully.
>> 
>> The issue is *not* about robot or no robot.
>> 
>> It is about this particular robot that causes so much noise.
> 
> Yes! That’s right so we need to figure out how to use the robot correctly!
> 
>> 
>>> 
>>> 
> On Dec 29, 2021, at 1:57 PM, Phil Steitz  > wrote:
 
 
 
> On 12/29/21 8:43 AM, sebb wrote:
>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory > > wrote:
>>> On Wed, Dec 29, 2021 at 9:42 AM sebb >> > wrote:
>> 
>>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory >> > wrote:
 On Wed, Dec 29, 2021 at 9:07 AM sebb >>> > wrote:
 
> On Wed, 29 Dec 2021 at 13:54, Gary Gregory  >
>>> wrote:
>> One critical feature is that dependabot does all the builds for you
>>> on
>> GitHub Actions, this is an enormous time and resource saver!
> Not at all.
> Just the reverse.
> 
> It does NOT save resources, because it runs builds for updates that
> are not necessary at that point in time (or ever, in some cases).
> 
> Nor does it same time, because the the noise that it generates.
> 
> 
> Please stop pretending that Dependabot does things it does not (and
> likely cannot) do.
> 
 Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
 It's as simple as I stated:
 
 If Dependabot detects that a new version of a dependency is available,
 creates a branch, runs a build, tells me the result and I have a PR I 
 can
 merge, *that is all work and time *I* do not have to do manually! Why 
 is
 that so hard to understand?*
>>> Of course I understand that.
>>> 
>> Phew! :-)
>> 
>>> However, just because a new version is available does NOT mean that it
>>> has to be updated there and then.
>>> Sometimes it never needs to be updated.
>>> 
>> You can't know if you need to make a decision unless someone asks you to
>> make it. I don't know out of thin air that a new version is available.
> You can be pro-active and do a dependency check yourself.
> And you can look out for security bulletins.
> 
> That's what we used to do.
> 
>>> Changes to dependencies occur much more frequently than component 
>>> releases.
>>> So often there will be several mails for the same dependency.
>>> 
>>> In the past, the approach was to check for new (and useful) updates
>>> shortly before a release.
>>> 
>> That must have been before my time and it seems like a horrible idea: The
>> software is stable after a few months of activity and it's time to make a
>> release, so the day before a release, you change all the dependencies, 
>> and
>> cross your fingers? Yikes!
> That is NOT what I said.
> 
> Obviously one would start working on version updates some time before
> the release.
> Days or weeks rather than months or years.
> 
>>> Generally all the versions would be updated at the same time, instead
>>> of individually.
>>> 
>> Not here, if update 10 dependencies and a build fails, then what? I go 
>> back
>> to square one and update each, one at a time, until I find the culprit,
>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
>> for components like VFS, Configuration, and others.
> Well yes, but how likely is there to be a failure in such circumstances?
> 
> If the build does not fail, you have saved the noise from at least 9
> updates which are generally 3 emails per update.
> 
> If it does fail, you will have wasted 2 cycles: the original commit of
> 10, and the revert. And only 2 emails.
 
 +1 and you will get many thanks from those trying to follow co

Re: can we get rid of dependabot?

[Rob Tompkins]

> On Dec 30, 2021, at 5:37 PM, sebb  wrote:
> 
> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  wrote:
>> 
>> Guys. The fundamental argument underpinng all this is whether it’s better to 
>> have robot eyes on the code and human eyes on the code. Stop arguing one 
>> side or the other. We need to find a way to do both successfully.
> 
> The issue is *not* about robot or no robot.
> 
> It is about this particular robot that causes so much noise.

Yes! That’s right so we need to figure out how to use the robot correctly!

> 
>> 
>> 
 On Dec 29, 2021, at 1:57 PM, Phil Steitz  wrote:
>>> 
>>> 
>>> 
 On 12/29/21 8:43 AM, sebb wrote:
> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  wrote:
>> On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
> 
>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory  
>> wrote:
>>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
>>> 
 On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
>> wrote:
> One critical feature is that dependabot does all the builds for you
>> on
> GitHub Actions, this is an enormous time and resource saver!
 Not at all.
 Just the reverse.
 
 It does NOT save resources, because it runs builds for updates that
 are not necessary at that point in time (or ever, in some cases).
 
 Nor does it same time, because the the noise that it generates.
 
 
 Please stop pretending that Dependabot does things it does not (and
 likely cannot) do.
 
>>> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
>>> It's as simple as I stated:
>>> 
>>> If Dependabot detects that a new version of a dependency is available,
>>> creates a branch, runs a build, tells me the result and I have a PR I 
>>> can
>>> merge, *that is all work and time *I* do not have to do manually! Why is
>>> that so hard to understand?*
>> Of course I understand that.
>> 
> Phew! :-)
> 
>> However, just because a new version is available does NOT mean that it
>> has to be updated there and then.
>> Sometimes it never needs to be updated.
>> 
> You can't know if you need to make a decision unless someone asks you to
> make it. I don't know out of thin air that a new version is available.
 You can be pro-active and do a dependency check yourself.
 And you can look out for security bulletins.
 
 That's what we used to do.
 
>> Changes to dependencies occur much more frequently than component 
>> releases.
>> So often there will be several mails for the same dependency.
>> 
>> In the past, the approach was to check for new (and useful) updates
>> shortly before a release.
>> 
> That must have been before my time and it seems like a horrible idea: The
> software is stable after a few months of activity and it's time to make a
> release, so the day before a release, you change all the dependencies, and
> cross your fingers? Yikes!
 That is NOT what I said.
 
 Obviously one would start working on version updates some time before
 the release.
 Days or weeks rather than months or years.
 
>> Generally all the versions would be updated at the same time, instead
>> of individually.
>> 
> Not here, if update 10 dependencies and a build fails, then what? I go 
> back
> to square one and update each, one at a time, until I find the culprit,
> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> for components like VFS, Configuration, and others.
 Well yes, but how likely is there to be a failure in such circumstances?
 
 If the build does not fail, you have saved the noise from at least 9
 updates which are generally 3 emails per update.
 
 If it does fail, you will have wasted 2 cycles: the original commit of
 10, and the revert. And only 2 emails.
>>> 
>>> +1 and you will get many thanks from those trying to follow commits and 
>>> better review of the actual commits.  It seems badly broken to me that in 
>>> order to effectively review commits to the commons components that I watch 
>>> I have to write filters to ignore most of them.  The damage from making it 
>>> harder to review commits is far greater than the benefit this thing 
>>> provides.  Actual code commits are where bugs and vulnerabilities get 
>>> introduced.  Just like mixing formatting changes with functional code 
>>> changes is a bad practice, spamming commits@ with a bunch of auto-branch 
>>> creations is bad as it dilutes eyeballs, which are the most important 
>>> community resource that we have in ensuring code quality and security.
>>> 
>>> Phil
 
> Gary
> 
> 
>>> Gary
>>> 
>>> 
> Gary
> 
> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> 
>> 
>>> On Dec 29, 2021, at 8:45 AM,

Re: can we get rid of dependabot?

[Gary Gregory]

This feels like a "Don't shoot the messenger" issue: Some people really
don't like this mail carrier and uniform ;-)

Gary

On Thu, Dec 30, 2021 at 5:37 PM sebb  wrote:

> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  wrote:
> >
> > Guys. The fundamental argument underpinng all this is whether it’s
> better to have robot eyes on the code and human eyes on the code. Stop
> arguing one side or the other. We need to find a way to do both
> successfully.
>
> The issue is *not* about robot or no robot.
>
> It is about this particular robot that causes so much noise.
>
> >
> >
> > > On Dec 29, 2021, at 1:57 PM, Phil Steitz 
> wrote:
> > >
> > > 
> > >
> > >> On 12/29/21 8:43 AM, sebb wrote:
> > >>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory 
> wrote:
> >  On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
> > >>>
> >  On Wed, 29 Dec 2021 at 14:18, Gary Gregory 
> wrote:
> > > On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> > >
> > >> On Wed, 29 Dec 2021 at 13:54, Gary Gregory <
> garydgreg...@gmail.com>
> >  wrote:
> > >>> One critical feature is that dependabot does all the builds for
> you
> >  on
> > >>> GitHub Actions, this is an enormous time and resource saver!
> > >> Not at all.
> > >> Just the reverse.
> > >>
> > >> It does NOT save resources, because it runs builds for updates
> that
> > >> are not necessary at that point in time (or ever, in some cases).
> > >>
> > >> Nor does it same time, because the the noise that it generates.
> > >>
> > >>
> > >> Please stop pretending that Dependabot does things it does not
> (and
> > >> likely cannot) do.
> > >>
> > > Oh, boy, Sebb, it feels like you are purposely misunderstanding my
> POV.
> > > It's as simple as I stated:
> > >
> > > If Dependabot detects that a new version of a dependency is
> available,
> > > creates a branch, runs a build, tells me the result and I have a
> PR I can
> > > merge, *that is all work and time *I* do not have to do manually!
> Why is
> > > that so hard to understand?*
> >  Of course I understand that.
> > 
> > >>> Phew! :-)
> > >>>
> >  However, just because a new version is available does NOT mean that
> it
> >  has to be updated there and then.
> >  Sometimes it never needs to be updated.
> > 
> > >>> You can't know if you need to make a decision unless someone asks
> you to
> > >>> make it. I don't know out of thin air that a new version is
> available.
> > >> You can be pro-active and do a dependency check yourself.
> > >> And you can look out for security bulletins.
> > >>
> > >> That's what we used to do.
> > >>
> >  Changes to dependencies occur much more frequently than component
> releases.
> >  So often there will be several mails for the same dependency.
> > 
> >  In the past, the approach was to check for new (and useful) updates
> >  shortly before a release.
> > 
> > >>> That must have been before my time and it seems like a horrible
> idea: The
> > >>> software is stable after a few months of activity and it's time to
> make a
> > >>> release, so the day before a release, you change all the
> dependencies, and
> > >>> cross your fingers? Yikes!
> > >> That is NOT what I said.
> > >>
> > >> Obviously one would start working on version updates some time before
> > >> the release.
> > >> Days or weeks rather than months or years.
> > >>
> >  Generally all the versions would be updated at the same time,
> instead
> >  of individually.
> > 
> > >>> Not here, if update 10 dependencies and a build fails, then what? I
> go back
> > >>> to square one and update each, one at a time, until I find the
> culprit,
> > >>> which to me is a waste of time. BTW, 10 dependencies is not
> unreasonable
> > >>> for components like VFS, Configuration, and others.
> > >> Well yes, but how likely is there to be a failure in such
> circumstances?
> > >>
> > >> If the build does not fail, you have saved the noise from at least 9
> > >> updates which are generally 3 emails per update.
> > >>
> > >> If it does fail, you will have wasted 2 cycles: the original commit of
> > >> 10, and the revert. And only 2 emails.
> > >
> > > +1 and you will get many thanks from those trying to follow commits
> and better review of the actual commits.  It seems badly broken to me that
> in order to effectively review commits to the commons components that I
> watch I have to write filters to ignore most of them.  The damage from
> making it harder to review commits is far greater than the benefit this
> thing provides.  Actual code commits are where bugs and vulnerabilities get
> introduced.  Just like mixing formatting changes with functional code
> changes is a bad practice, spamming commits@ with a bunch of auto-branch
> creations is bad as it dilutes eyeballs, which are the most important
> community resource that we have in ensuring code quality and security.
> > >
> > > Phil
> > >>
> > >>> Ga

Re: can we get rid of dependabot?

[sebb]

On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  wrote:
>
> Guys. The fundamental argument underpinng all this is whether it’s better to 
> have robot eyes on the code and human eyes on the code. Stop arguing one side 
> or the other. We need to find a way to do both successfully.

The issue is *not* about robot or no robot.

It is about this particular robot that causes so much noise.

>
>
> > On Dec 29, 2021, at 1:57 PM, Phil Steitz  wrote:
> >
> > 
> >
> >> On 12/29/21 8:43 AM, sebb wrote:
> >>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  wrote:
>  On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
> >>>
>  On Wed, 29 Dec 2021 at 14:18, Gary Gregory  
>  wrote:
> > On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> >
> >> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
>  wrote:
> >>> One critical feature is that dependabot does all the builds for you
>  on
> >>> GitHub Actions, this is an enormous time and resource saver!
> >> Not at all.
> >> Just the reverse.
> >>
> >> It does NOT save resources, because it runs builds for updates that
> >> are not necessary at that point in time (or ever, in some cases).
> >>
> >> Nor does it same time, because the the noise that it generates.
> >>
> >>
> >> Please stop pretending that Dependabot does things it does not (and
> >> likely cannot) do.
> >>
> > Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> > It's as simple as I stated:
> >
> > If Dependabot detects that a new version of a dependency is available,
> > creates a branch, runs a build, tells me the result and I have a PR I 
> > can
> > merge, *that is all work and time *I* do not have to do manually! Why is
> > that so hard to understand?*
>  Of course I understand that.
> 
> >>> Phew! :-)
> >>>
>  However, just because a new version is available does NOT mean that it
>  has to be updated there and then.
>  Sometimes it never needs to be updated.
> 
> >>> You can't know if you need to make a decision unless someone asks you to
> >>> make it. I don't know out of thin air that a new version is available.
> >> You can be pro-active and do a dependency check yourself.
> >> And you can look out for security bulletins.
> >>
> >> That's what we used to do.
> >>
>  Changes to dependencies occur much more frequently than component 
>  releases.
>  So often there will be several mails for the same dependency.
> 
>  In the past, the approach was to check for new (and useful) updates
>  shortly before a release.
> 
> >>> That must have been before my time and it seems like a horrible idea: The
> >>> software is stable after a few months of activity and it's time to make a
> >>> release, so the day before a release, you change all the dependencies, and
> >>> cross your fingers? Yikes!
> >> That is NOT what I said.
> >>
> >> Obviously one would start working on version updates some time before
> >> the release.
> >> Days or weeks rather than months or years.
> >>
>  Generally all the versions would be updated at the same time, instead
>  of individually.
> 
> >>> Not here, if update 10 dependencies and a build fails, then what? I go 
> >>> back
> >>> to square one and update each, one at a time, until I find the culprit,
> >>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> >>> for components like VFS, Configuration, and others.
> >> Well yes, but how likely is there to be a failure in such circumstances?
> >>
> >> If the build does not fail, you have saved the noise from at least 9
> >> updates which are generally 3 emails per update.
> >>
> >> If it does fail, you will have wasted 2 cycles: the original commit of
> >> 10, and the revert. And only 2 emails.
> >
> > +1 and you will get many thanks from those trying to follow commits and 
> > better review of the actual commits.  It seems badly broken to me that in 
> > order to effectively review commits to the commons components that I watch 
> > I have to write filters to ignore most of them.  The damage from making it 
> > harder to review commits is far greater than the benefit this thing 
> > provides.  Actual code commits are where bugs and vulnerabilities get 
> > introduced.  Just like mixing formatting changes with functional code 
> > changes is a bad practice, spamming commits@ with a bunch of auto-branch 
> > creations is bad as it dilutes eyeballs, which are the most important 
> > community resource that we have in ensuring code quality and security.
> >
> > Phil
> >>
> >>> Gary
> >>>
> >>>
> > Gary
> >
> >
> >>> Gary
> >>>
> >>> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> >>>
> 
> > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
>  wrote:
> > @Rob: dependabot is mainly about dependencies upgrades and it is
> >> also
>  why
> >

Re: can we get rid of dependabot?

[Rob Tompkins]

Guys. The fundamental argument underpinng all this is whether it’s better to 
have robot eyes on the code and human eyes on the code. Stop arguing one side 
or the other. We need to find a way to do both successfully. 



> On Dec 29, 2021, at 1:57 PM, Phil Steitz  wrote:
> 
> 
> 
>> On 12/29/21 8:43 AM, sebb wrote:
>>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  wrote:
 On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
>>> 
 On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:
> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> 
>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
 wrote:
>>> One critical feature is that dependabot does all the builds for you
 on
>>> GitHub Actions, this is an enormous time and resource saver!
>> Not at all.
>> Just the reverse.
>> 
>> It does NOT save resources, because it runs builds for updates that
>> are not necessary at that point in time (or ever, in some cases).
>> 
>> Nor does it same time, because the the noise that it generates.
>> 
>> 
>> Please stop pretending that Dependabot does things it does not (and
>> likely cannot) do.
>> 
> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> It's as simple as I stated:
> 
> If Dependabot detects that a new version of a dependency is available,
> creates a branch, runs a build, tells me the result and I have a PR I can
> merge, *that is all work and time *I* do not have to do manually! Why is
> that so hard to understand?*
 Of course I understand that.
 
>>> Phew! :-)
>>> 
 However, just because a new version is available does NOT mean that it
 has to be updated there and then.
 Sometimes it never needs to be updated.
 
>>> You can't know if you need to make a decision unless someone asks you to
>>> make it. I don't know out of thin air that a new version is available.
>> You can be pro-active and do a dependency check yourself.
>> And you can look out for security bulletins.
>> 
>> That's what we used to do.
>> 
 Changes to dependencies occur much more frequently than component releases.
 So often there will be several mails for the same dependency.
 
 In the past, the approach was to check for new (and useful) updates
 shortly before a release.
 
>>> That must have been before my time and it seems like a horrible idea: The
>>> software is stable after a few months of activity and it's time to make a
>>> release, so the day before a release, you change all the dependencies, and
>>> cross your fingers? Yikes!
>> That is NOT what I said.
>> 
>> Obviously one would start working on version updates some time before
>> the release.
>> Days or weeks rather than months or years.
>> 
 Generally all the versions would be updated at the same time, instead
 of individually.
 
>>> Not here, if update 10 dependencies and a build fails, then what? I go back
>>> to square one and update each, one at a time, until I find the culprit,
>>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
>>> for components like VFS, Configuration, and others.
>> Well yes, but how likely is there to be a failure in such circumstances?
>> 
>> If the build does not fail, you have saved the noise from at least 9
>> updates which are generally 3 emails per update.
>> 
>> If it does fail, you will have wasted 2 cycles: the original commit of
>> 10, and the revert. And only 2 emails.
> 
> +1 and you will get many thanks from those trying to follow commits and 
> better review of the actual commits.  It seems badly broken to me that in 
> order to effectively review commits to the commons components that I watch I 
> have to write filters to ignore most of them.  The damage from making it 
> harder to review commits is far greater than the benefit this thing provides. 
>  Actual code commits are where bugs and vulnerabilities get introduced.  Just 
> like mixing formatting changes with functional code changes is a bad 
> practice, spamming commits@ with a bunch of auto-branch creations is bad as 
> it dilutes eyeballs, which are the most important community resource that we 
> have in ensuring code quality and security.
> 
> Phil
>> 
>>> Gary
>>> 
>>> 
> Gary
> 
> 
>>> Gary
>>> 
>>> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
>>> 
 
> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
 wrote:
> @Rob: dependabot is mainly about dependencies upgrades and it is
>> also
 why
> it is so chatty and has so much false positives.
 Yes, I am well aware. But I do not see how a robot telling you to
>> simply
 upgrade is a problem?
 
 Maybe I’m missing something but my impression is that’s what
 dependabot
 does right? Tell you you need to upgrade?
 
 -Rob
 
> If you want to focus o

Re: can we get rid of dependabot?

[Bruno P. Kinoshita]

 Hi,

I would prefer a solution that fixes the email issue, but if it bothers others, 
I guess I could enable dependabot on my fork of commons-imaging, commons-lang, 
commons-text, or any other repository that I may RM one day.

I use dependabot in other personal and $work projects and it's very helpful for 
Python & JS. Especially JS, where some updates may prevent security issues - 
even if you don't have a CVE in one of these dependencies, it's common that 
transitive dependencies have a CVE and due to how version ranges work in JS 
it's much more common to be affected indirectly, so I use dependabot and other 
tools like ncu to scan for updates.

For Java I normally see the security warnings in the GitHub security 
tab/HackerNews/Twitter/etc and fix it before dependabot can send a PR - this 
was the case in Apache Jena for log4j2, a few days ago.


For the Java projects, I find that it helps me knowing when things are broken 
due to updates. Like new versions of SpotBugs or Checkstyle that break the 
code. I prefer to fix that as soon as I have spare time, rather than when 
during a release. With Imaging, in alpha-1 release I think, I had a short 2-3 
days period to prepare the release, and during the step of updating 
dependencies, I found some FindBugs issues reported by the new version I was 
updating to, and spent the whole 2-3 days fixing it, then had to wait for 
another time to try to release again.

So if there is no solution for the noise that dependabot causes, I will use my 
fork with dependabot enabled to monitor if any PR fails, and see if it is 
something important.


-Bruno

On Wednesday, 29 December 2021, 07:20:35 am NZDT, Phil Steitz 
 wrote:  
 
 I can no longer effectively monitor commits@ due to the spam generated 
by this tool.  I am afraid my eyeballs aren't the only ones going 
missing here and that is a problem much more severe than any value 
provided by this tool, IMO.

Phil

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

  

Re: can we get rid of dependabot?

[Phil Steitz]

On 12/29/21 8:43 AM, sebb wrote:

On Wed, 29 Dec 2021 at 14:53, Gary Gregory  wrote:

On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:


On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:

On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:


On Wed, 29 Dec 2021 at 13:54, Gary Gregory 

wrote:

One critical feature is that dependabot does all the builds for you

on

GitHub Actions, this is an enormous time and resource saver!

Not at all.
Just the reverse.

It does NOT save resources, because it runs builds for updates that
are not necessary at that point in time (or ever, in some cases).

Nor does it same time, because the the noise that it generates.


Please stop pretending that Dependabot does things it does not (and
likely cannot) do.


Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
It's as simple as I stated:

If Dependabot detects that a new version of a dependency is available,
creates a branch, runs a build, tells me the result and I have a PR I can
merge, *that is all work and time *I* do not have to do manually! Why is
that so hard to understand?*

Of course I understand that.


Phew! :-)


However, just because a new version is available does NOT mean that it
has to be updated there and then.
Sometimes it never needs to be updated.


You can't know if you need to make a decision unless someone asks you to
make it. I don't know out of thin air that a new version is available.

You can be pro-active and do a dependency check yourself.
And you can look out for security bulletins.

That's what we used to do.


Changes to dependencies occur much more frequently than component releases.
So often there will be several mails for the same dependency.

In the past, the approach was to check for new (and useful) updates
shortly before a release.


That must have been before my time and it seems like a horrible idea: The
software is stable after a few months of activity and it's time to make a
release, so the day before a release, you change all the dependencies, and
cross your fingers? Yikes!

That is NOT what I said.

Obviously one would start working on version updates some time before
the release.
Days or weeks rather than months or years.


Generally all the versions would be updated at the same time, instead
of individually.


Not here, if update 10 dependencies and a build fails, then what? I go back
to square one and update each, one at a time, until I find the culprit,
which to me is a waste of time. BTW, 10 dependencies is not unreasonable
for components like VFS, Configuration, and others.

Well yes, but how likely is there to be a failure in such circumstances?

If the build does not fail, you have saved the noise from at least 9
updates which are generally 3 emails per update.

If it does fail, you will have wasted 2 cycles: the original commit of
10, and the revert. And only 2 emails.


+1 and you will get many thanks from those trying to follow commits and 
better review of the actual commits.  It seems badly broken to me that 
in order to effectively review commits to the commons components that I 
watch I have to write filters to ignore most of them.  The damage from 
making it harder to review commits is far greater than the benefit this 
thing provides.  Actual code commits are where bugs and vulnerabilities 
get introduced.  Just like mixing formatting changes with functional 
code changes is a bad practice, spamming commits@ with a bunch of 
auto-branch creations is bad as it dilutes eyeballs, which are the most 
important community resource that we have in ensuring code quality and 
security.


Phil



Gary



Gary



Gary

On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:




On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:

@Rob: dependabot is mainly about dependencies upgrades and it is

also

why

it is so chatty and has so much false positives.

Yes, I am well aware. But I do not see how a robot telling you to

simply

upgrade is a problem?

Maybe I’m missing something but my impression is that’s what

dependabot

does right? Tell you you need to upgrade?

-Rob


If you want to focus on
CVE then setting up on the CI
https://sonatype.github.io/ossindex-maven/maven-plugin/ is way

more

efficient and accurate (basically when it fails you must act) so

dependabot

is a great reporting tool for managers but not to work on an

everyday

basis

IMHO until it is very finely configure but commons is far to

need so

much

investment since there already have solutions for everything

needed

IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance




Le mer. 29 déc. 2021 à 14:39, Rob Tompkins 

a

écrit :

Guys. I think dependabot is our greatest advant

Re: can we get rid of dependabot?

[Matt Sicker]

All these version pins, notification settings, etc., are all configurable in 
the Dependabot config file.
--
Matt Sicker

> On Dec 29, 2021, at 09:22, Romain Manni-Bucau  wrote:
> 
> @Rob: not sure dependabot would get commits permissions anytime soon, it is
> really an automotion thing on one side - we already had since years before
> dependabot was a thing BTW - and it would be a poor committer on another
> side, since it does changes without validating them or reviewing its impact
> in the downstream projects - once again you get a lot of broken PR with
> dependabot, I can see commons is not that affected because the dependencies
> of commons are light in general but look any other project, it is pure
> noise and a good way to break the project (incompatibility with a
> dependency, broken OSGi metada, upgrade making a change at compile time -
> bytecode breaking change which is invisible with any test suite until you
> use compare with previous version - clirr or alike + test, plus it would
> enable to use an up to date API when you need to support more so you can
> break your consumers - upgrade junit5 to 5.8 and start using 5.8 API when
> you must support users relying on junit 5.6 for ex). So the question is
> 100% the ROI. Dependabot doing a lot of noise and enforcing a lot of work -
> if not ignored - it costs a lot whereas dependency upgrades and CVE
> management is very very cheap in a project life, even for big ones like
> Apache TomEE, so don't think it can be justified as of today.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 29 déc. 2021 à 16:10, Rob Tompkins  a écrit :
> 
>> Guys….let us blind our eyes to the source. We are taking about kicking our
>> most excited contributor. Are we not? If dependabot were a person they
>> would likely have gotten commit rights and be in the PMC. Granted, they’d
>> have taken some advice and slowed down a bit and maybe with some steering
>> we can accomplish just that.
>> 
>> My last penny,
>> -Rob
>> 
>>> On Dec 29, 2021, at 9:53 AM, Gary Gregory 
>> wrote:
>>> 
>>> On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
>>> 
> On Wed, 29 Dec 2021 at 14:18, Gary Gregory 
>> wrote:
> 
>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> 
>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
 wrote:
>>> 
>>> One critical feature is that dependabot does all the builds for you
 on
>>> GitHub Actions, this is an enormous time and resource saver!
>> 
>> Not at all.
>> Just the reverse.
>> 
>> It does NOT save resources, because it runs builds for updates that
>> are not necessary at that point in time (or ever, in some cases).
>> 
>> Nor does it same time, because the the noise that it generates.
>> 
>> 
> 
>> Please stop pretending that Dependabot does things it does not (and
>> likely cannot) do.
>> 
> 
> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> It's as simple as I stated:
> 
> If Dependabot detects that a new version of a dependency is available,
> creates a branch, runs a build, tells me the result and I have a PR I
>> can
> merge, *that is all work and time *I* do not have to do manually! Why
>> is
> that so hard to understand?*
 
 Of course I understand that.
 
>>> 
>>> Phew! :-)
>>> 
 
 However, just because a new version is available does NOT mean that it
 has to be updated there and then.
 Sometimes it never needs to be updated.
 
>>> 
>>> You can't know if you need to make a decision unless someone asks you to
>>> make it. I don't know out of thin air that a new version is available.
>>> 
>>> 
 
 Changes to dependencies occur much more frequently than component
>> releases.
 So often there will be several mails for the same dependency.
 
 In the past, the approach was to check for new (and useful) updates
 shortly before a release.
 
>>> 
>>> That must have been before my time and it seems like a horrible idea: The
>>> software is stable after a few months of activity and it's time to make a
>>> release, so the day before a release, you change all the dependencies,
>> and
>>> cross your fingers? Yikes!
>>> 
>>> 
 Generally all the versions would be updated at the same time, instead
 of individually.
 
>>> 
>>> Not here, if update 10 dependencies and a build fails, then what? I go
>> back
>>> to square one and update each, one at a time, until I find the culprit,
>>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
>>> for components like VFS, Configuration, and others.
>>> 
>>> Gary
>>> 
>>> 
> Gary

Re: can we get rid of dependabot?

[Rob Tompkins]

I still yet don’t see how thoughtful automation using dependabot doesn’t win 
out. 

So the idea behind using a double negative in a sentence like above, is to 
imply that there is more than just a “yes/no” answer to the question. There is 
the beginnings (a few choices) of a veritable continuum of possibilities using 
computers to help us here with our security. The question isn’t if we 
implement!!! It’s how* we implement. 

-Rob

> On Dec 29, 2021, at 10:44 AM, sebb  wrote:
> 
> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  wrote:
>> 
>>> On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
>>> 
>>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:
 
 On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
 
> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
>>> wrote:
>> 
>> One critical feature is that dependabot does all the builds for you
>>> on
>> GitHub Actions, this is an enormous time and resource saver!
> 
> Not at all.
> Just the reverse.
> 
> It does NOT save resources, because it runs builds for updates that
> are not necessary at that point in time (or ever, in some cases).
> 
> Nor does it same time, because the the noise that it generates.
> 
> 
 
> Please stop pretending that Dependabot does things it does not (and
> likely cannot) do.
> 
 
 Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
 It's as simple as I stated:
 
 If Dependabot detects that a new version of a dependency is available,
 creates a branch, runs a build, tells me the result and I have a PR I can
 merge, *that is all work and time *I* do not have to do manually! Why is
 that so hard to understand?*
>>> 
>>> Of course I understand that.
>>> 
>> 
>> Phew! :-)
>> 
>>> 
>>> However, just because a new version is available does NOT mean that it
>>> has to be updated there and then.
>>> Sometimes it never needs to be updated.
>>> 
>> 
>> You can't know if you need to make a decision unless someone asks you to
>> make it. I don't know out of thin air that a new version is available.
> 
> You can be pro-active and do a dependency check yourself.
> And you can look out for security bulletins.
> 
> That's what we used to do.
> 
>> 
>>> 
>>> Changes to dependencies occur much more frequently than component releases.
>>> So often there will be several mails for the same dependency.
>>> 
>>> In the past, the approach was to check for new (and useful) updates
>>> shortly before a release.
>>> 
>> 
>> That must have been before my time and it seems like a horrible idea: The
>> software is stable after a few months of activity and it's time to make a
>> release, so the day before a release, you change all the dependencies, and
>> cross your fingers? Yikes!
> 
> That is NOT what I said.
> 
> Obviously one would start working on version updates some time before
> the release.
> Days or weeks rather than months or years.
> 
>> 
>>> Generally all the versions would be updated at the same time, instead
>>> of individually.
>>> 
>> 
>> Not here, if update 10 dependencies and a build fails, then what? I go back
>> to square one and update each, one at a time, until I find the culprit,
>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
>> for components like VFS, Configuration, and others.
> 
> Well yes, but how likely is there to be a failure in such circumstances?
> 
> If the build does not fail, you have saved the noise from at least 9
> updates which are generally 3 emails per update.
> 
> If it does fail, you will have wasted 2 cycles: the original commit of
> 10, and the revert. And only 2 emails.
> 
>> Gary
>> 
>> 
 Gary
 
 
>> Gary
>> 
>> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
>> 
>>> 
>>> 
 On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
>>> wrote:
 
 @Rob: dependabot is mainly about dependencies upgrades and it is
> also
>>> why
 it is so chatty and has so much false positives.
>>> 
>>> Yes, I am well aware. But I do not see how a robot telling you to
> simply
>>> upgrade is a problem?
>>> 
>>> Maybe I’m missing something but my impression is that’s what
>>> dependabot
>>> does right? Tell you you need to upgrade?
>>> 
>>> -Rob
>>> 
 If you want to focus on
 CVE then setting up on the CI
 https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
>>> more
 efficient and accurate (basically when it fails you must act) so
>>> dependabot
 is a great reporting tool for managers but not to work on an
>>> everyday
>>> basis
 IMHO until it is very finely configure but commons is far to
>>> need so
> much
 investment since there already have solutions for everything
>>> needed
> IMHO.
 
 Romain Manni-Bucau
 @rmannibucau 

Re: can we get rid of dependabot?

[sebb]

On Wed, 29 Dec 2021 at 14:53, Gary Gregory  wrote:
>
> On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
>
> > On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:
> > >
> > > On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> > >
> > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> > wrote:
> > > > >
> > > > > One critical feature is that dependabot does all the builds for you
> > on
> > > > > GitHub Actions, this is an enormous time and resource saver!
> > > >
> > > > Not at all.
> > > > Just the reverse.
> > > >
> > > > It does NOT save resources, because it runs builds for updates that
> > > > are not necessary at that point in time (or ever, in some cases).
> > > >
> > > > Nor does it same time, because the the noise that it generates.
> > > >
> > > >
> > >
> > > > Please stop pretending that Dependabot does things it does not (and
> > > > likely cannot) do.
> > > >
> > >
> > > Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> > > It's as simple as I stated:
> > >
> > > If Dependabot detects that a new version of a dependency is available,
> > > creates a branch, runs a build, tells me the result and I have a PR I can
> > > merge, *that is all work and time *I* do not have to do manually! Why is
> > > that so hard to understand?*
> >
> > Of course I understand that.
> >
>
> Phew! :-)
>
> >
> > However, just because a new version is available does NOT mean that it
> > has to be updated there and then.
> > Sometimes it never needs to be updated.
> >
>
> You can't know if you need to make a decision unless someone asks you to
> make it. I don't know out of thin air that a new version is available.

You can be pro-active and do a dependency check yourself.
And you can look out for security bulletins.

That's what we used to do.

>
> >
> > Changes to dependencies occur much more frequently than component releases.
> > So often there will be several mails for the same dependency.
> >
> > In the past, the approach was to check for new (and useful) updates
> > shortly before a release.
> >
>
> That must have been before my time and it seems like a horrible idea: The
> software is stable after a few months of activity and it's time to make a
> release, so the day before a release, you change all the dependencies, and
> cross your fingers? Yikes!

That is NOT what I said.

Obviously one would start working on version updates some time before
the release.
Days or weeks rather than months or years.

>
> > Generally all the versions would be updated at the same time, instead
> > of individually.
> >
>
> Not here, if update 10 dependencies and a build fails, then what? I go back
> to square one and update each, one at a time, until I find the culprit,
> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> for components like VFS, Configuration, and others.

Well yes, but how likely is there to be a failure in such circumstances?

If the build does not fail, you have saved the noise from at least 9
updates which are generally 3 emails per update.

If it does fail, you will have wasted 2 cycles: the original commit of
10, and the revert. And only 2 emails.

> Gary
>
>
> > > Gary
> > >
> > >
> > > > > Gary
> > > > >
> > > > > On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > @Rob: dependabot is mainly about dependencies upgrades and it is
> > > > also
> > > > > > why
> > > > > > > it is so chatty and has so much false positives.
> > > > > >
> > > > > > Yes, I am well aware. But I do not see how a robot telling you to
> > > > simply
> > > > > > upgrade is a problem?
> > > > > >
> > > > > > Maybe I’m missing something but my impression is that’s what
> > dependabot
> > > > > > does right? Tell you you need to upgrade?
> > > > > >
> > > > > > -Rob
> > > > > >
> > > > > > > If you want to focus on
> > > > > > > CVE then setting up on the CI
> > > > > > > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> > more
> > > > > > > efficient and accurate (basically when it fails you must act) so
> > > > > > dependabot
> > > > > > > is a great reporting tool for managers but not to work on an
> > everyday
> > > > > > basis
> > > > > > > IMHO until it is very finely configure but commons is far to
> > need so
> > > > much
> > > > > > > investment since there already have solutions for everything
> > needed
> > > > IMHO.
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau  |  Blog
> > > > > > >  | Old Blog
> > > > > > >  | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn  | Book
> > > > > > > <
> > > > > >
> > > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > >
> > > > > > >

Re: can we get rid of dependabot?

[Rob Tompkins]

> On Dec 29, 2021, at 10:29 AM, Matt Benson  wrote:
> 
> On Wed, Dec 29, 2021, 9:21 AM Mark Thomas  wrote:
> 
>>> On 29/12/2021 15:04, Gary Gregory wrote:
 On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins  wrote:
>>> 
 Why not just run dependabot weekly. We move slowly enough that weekly
 currently works. Until we can get more hands on the project, slower
>> comms
 are indeed reasonable…right?
 
>>> 
>>> I would be OK with it once a week.
>> 
>> I think the improvement resulting from moving to once a week will be
>> minimal.
>> 
>> I get the desire to keep things up to date but the way dependabot is
>> currently working creates a lot of traffic on both issues@ and commits@
>> That noise makes it much harder to follow any other activity that might
>> be happening in the project. I am finding it a lot more effort to keep
>> track of the Commons projects I am interested in.
>> 
>> Most commons libraries have very few "real" dependencies. Most of the
>> dependencies are there to support testing or building. I would argue
>> that updates to test/build libraries are far less critical and low risk
>> to update en masse just before a release.
>> 
>> I may look at applying local filters in the short term but that strikes
>> me very much as fixing the symptom rather than the cause and I don't
>> think it is efficient for every subscriber to have to do this if there
>> is an approach available that addresses the root cause.
>> 
>> As an aside, we also need to keep repeatable builds in mind. Simply
>> defining a version dependency as "latest" (or anything other than an
>> explicit version) is going to be problematic.
>> 
>> So, is there a way we could do something like the following with any
>> combination of dependabot and/or Versions Maven plugin and/or something
>> else?
>> 
>> - dependabot like behaviour (daily check, separate PR) for dependencies
>>   that are used (required or optional) at runtime
>> 
>> - a weekly (or even monthly?) check for test libraries, build tools etc.
>>   (i.e. everything that isn't a runtime dependency) that provides,
>>   ideally, a single PR with one commit per update
>> 
>> Emphasis on the "something like" the above.
>> 
> 

+1

> To jump into the discussion, I think these are sensible and constructive
> suggestions.
> 
> Matt
> 
> Mark
>> 
>> -
>> 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

Re: can we get rid of dependabot?

[Matt Benson]

On Wed, Dec 29, 2021, 9:27 AM Gary Gregory  wrote:

> On Wed, Dec 29, 2021 at 9:45 AM sebb  wrote:
>
> > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins  wrote:
> > >
> > > Why not just run dependabot weekly. We move slowly enough that weekly
> > currently works. Until we can get more hands on the project, slower comms
> > are indeed reasonable…right?
> >
> > Weekly runs won't reduce the number of emails, except where a single
> > dependency has been updated twice in a week.
> >
>
> I'm baffled by your reply: If I get one email a day for a week for a new
> dependency version, that's 7 emails. If I get one email a week for a
> dependency, let me see..., that's one a week. So it's seven times LESS. x


But typically:
- a given dependency has only been released at most once during the
preceding week
- the generated PRs are one per dependency

I think these are the reasons why it was said that running once a week
would not change the level of generated traffic significantly. It becomes a
matter of when rather than if the upgrade prompt comes.

Matt


> Gary
>
> >
> > I don't see how it is possible to reduce the noise from dependabot.
> >
> > > -Rob
> > >
> > > > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> > > >
> > > > Saving dev/human resources is about having a CI, all mentionned
> > plugins of
> > > > the thread support it properly while cronned.
> > > > Difference is the scope of the checks: CVE only, all deps, plugins
> and
> > code
> > > > (which is where most people don't like since it is trivial to have
> > false
> > > > positive and dependabot falls there).
> > > >
> > > > I agree CVE are a crucial topic but dependabot is NOT done for them,
> > it is
> > > > done for dependencies as a whole and is full of bugs so until it is
> > refined
> > > > to be more relevant and bulked differently (maybe *1* mail a week)
> > then it
> > > > is not an option for an everyday work IMHO.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > > >
> > > >
> > > >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory 
> a
> > > >> écrit :
> > > >>
> > > >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> > > >>>
> > > >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory  >
> > > >> wrote:
> > > 
> > >  One critical feature is that dependabot does all the builds for
> you
> > on
> > >  GitHub Actions, this is an enormous time and resource saver!
> > > >>>
> > > >>> Not at all.
> > > >>> Just the reverse.
> > > >>>
> > > >>> It does NOT save resources, because it runs builds for updates that
> > > >>> are not necessary at that point in time (or ever, in some cases).
> > > >>>
> > > >>> Nor does it same time, because the the noise that it generates.
> > > >>>
> > > >>>
> > > >>
> > > >>> Please stop pretending that Dependabot does things it does not (and
> > > >>> likely cannot) do.
> > > >>>
> > > >>
> > > >> Oh, boy, Sebb, it feels like you are purposely misunderstanding my
> > POV.
> > > >> It's as simple as I stated:
> > > >>
> > > >> If Dependabot detects that a new version of a dependency is
> available,
> > > >> creates a branch, runs a build, tells me the result and I have a PR
> I
> > can
> > > >> merge, *that is all work and time *I* do not have to do manually!
> Why
> > is
> > > >> that so hard to understand?*
> > > >>
> > > >> Gary
> > > >>
> > > >>
> > >  Gary
> > > 
> > >  On Wed, Dec 29, 2021, 08:51 Rob Tompkins 
> > wrote:
> > > 
> > > >
> > > >
> > > >> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > > >>> rmannibu...@gmail.com>
> > > > wrote:
> > > >>
> > > >> @Rob: dependabot is mainly about dependencies upgrades and it
> is
> > > >>> also
> > > > why
> > > >> it is so chatty and has so much false positives.
> > > >
> > > > Yes, I am well aware. But I do not see how a robot telling you to
> > > >>> simply
> > > > upgrade is a problem?
> > > >
> > > > Maybe I’m missing something but my impression is that’s what
> > > >> dependabot
> > > > does right? Tell you you need to upgrade?
> > > >
> > > > -Rob
> > > >
> > > >> If you want to focus on
> > > >> CVE then setting up on the CI
> > > >> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> > > >> more
> > > >> efficient and accurate (basically when it fails you must act) so
> > > > dependabot
> > > >> is a great reporting tool for managers but not to work on an
> > > >> everyday
> > > > basis
> > > >> IMHO until it is very finely configure but commons is far to
> need
> > > >> so
> > > >>> much
> > > >> investment since there alread

Re: can we get rid of dependabot?

[sebb]

On Wed, 29 Dec 2021 at 15:32, Romain Manni-Bucau  wrote:
>
> BTW: we always think about "commons" but there is not really a "commons"
> but there are commons so why not letting each project "lead" - the people
> actually working on the project which means it can change later - handling
> it. While it is a toggle to enable in asf.yaml or as easy as that I think
> it can be a solution. Then only point to discuss is:
> dependabot-notificatons@ per project or not - here again it makes sense per
> project IMHO since we are far behind a consistent thing where anyone
> contributing to one project cn contribute to all projects these day, no?
> Can't it be the way to solve it for everyone (lovers and hates of
> dependabot)?

That would only work if:
- there was a separate set of lists for each component
- set of component developers agreed on whether to use it

> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mer. 29 déc. 2021 à 16:28, Romain Manni-Bucau  a
> écrit :
>
> > @Gary thing is it is not one email per period but a much email as upgrades
> > per period with dependabot, there is no bulk email feature
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> > 
> >
> >
> > Le mer. 29 déc. 2021 à 16:27, Gary Gregory  a
> > écrit :
> >
> >> On Wed, Dec 29, 2021 at 9:45 AM sebb  wrote:
> >>
> >> > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins  wrote:
> >> > >
> >> > > Why not just run dependabot weekly. We move slowly enough that weekly
> >> > currently works. Until we can get more hands on the project, slower
> >> comms
> >> > are indeed reasonable…right?
> >> >
> >> > Weekly runs won't reduce the number of emails, except where a single
> >> > dependency has been updated twice in a week.
> >> >
> >>
> >> I'm baffled by your reply: If I get one email a day for a week for a new
> >> dependency version, that's 7 emails. If I get one email a week for a
> >> dependency, let me see..., that's one a week. So it's seven times LESS.
> >>
> >> Gary
> >>
> >> >
> >> > I don't see how it is possible to reduce the noise from dependabot.
> >> >
> >> > > -Rob
> >> > >
> >> > > > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> > > >
> >> > > > Saving dev/human resources is about having a CI, all mentionned
> >> > plugins of
> >> > > > the thread support it properly while cronned.
> >> > > > Difference is the scope of the checks: CVE only, all deps, plugins
> >> and
> >> > code
> >> > > > (which is where most people don't like since it is trivial to have
> >> > false
> >> > > > positive and dependabot falls there).
> >> > > >
> >> > > > I agree CVE are a crucial topic but dependabot is NOT done for them,
> >> > it is
> >> > > > done for dependencies as a whole and is full of bugs so until it is
> >> > refined
> >> > > > to be more relevant and bulked differently (maybe *1* mail a week)
> >> > then it
> >> > > > is not an option for an everyday work IMHO.
> >> > > >
> >> > > > Romain Manni-Bucau
> >> > > > @rmannibucau  |  Blog
> >> > > >  | Old Blog
> >> > > >  | Github <
> >> > https://github.com/rmannibucau> |
> >> > > > LinkedIn  | Book
> >> > > > <
> >> >
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> > >
> >> > > >
> >> > > >
> >> > > >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory 
> >> a
> >> > > >> écrit :
> >> > > >>
> >> > > >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> >> > > >>>
> >> > > >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory <
> >> garydgreg...@gmail.com>
> >> > > >> wrote:
> >> > > 
> >> > >  One critical feature is that dependabot does all the builds for
> >> you
> >> > on
> >> > >  GitHub Actions, this is an enormous time and resource saver!
> >> > > >>>
> >> > > >>> Not at all.
> >> > > >>> Just the reverse.
> >> > > >>>
> >> > > >>> It does NOT save resources, because it runs builds for updates
> >> that
> >> > > >>> are not necessary at that point in time (or ever, in some cases).
> >> > > >>>
> >> > > >>> Nor does it same time, because the the noise that it generates.
> >> > > >>>
> >> > > >>>
> >> > > >>
> >> > > >>> Please stop pretending that Dependabot does things it does not
> >> (and
> >> > > >>> likely cannot) do.
> >> > > >>>
> >> > > >>
> >> > > >>

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

BTW: we always think about "commons" but there is not really a "commons"
but there are commons so why not letting each project "lead" - the people
actually working on the project which means it can change later - handling
it. While it is a toggle to enable in asf.yaml or as easy as that I think
it can be a solution. Then only point to discuss is:
dependabot-notificatons@ per project or not - here again it makes sense per
project IMHO since we are far behind a consistent thing where anyone
contributing to one project cn contribute to all projects these day, no?
Can't it be the way to solve it for everyone (lovers and hates of
dependabot)?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 29 déc. 2021 à 16:28, Romain Manni-Bucau  a
écrit :

> @Gary thing is it is not one email per period but a much email as upgrades
> per period with dependabot, there is no bulk email feature
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mer. 29 déc. 2021 à 16:27, Gary Gregory  a
> écrit :
>
>> On Wed, Dec 29, 2021 at 9:45 AM sebb  wrote:
>>
>> > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins  wrote:
>> > >
>> > > Why not just run dependabot weekly. We move slowly enough that weekly
>> > currently works. Until we can get more hands on the project, slower
>> comms
>> > are indeed reasonable…right?
>> >
>> > Weekly runs won't reduce the number of emails, except where a single
>> > dependency has been updated twice in a week.
>> >
>>
>> I'm baffled by your reply: If I get one email a day for a week for a new
>> dependency version, that's 7 emails. If I get one email a week for a
>> dependency, let me see..., that's one a week. So it's seven times LESS.
>>
>> Gary
>>
>> >
>> > I don't see how it is possible to reduce the noise from dependabot.
>> >
>> > > -Rob
>> > >
>> > > > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> > > >
>> > > > Saving dev/human resources is about having a CI, all mentionned
>> > plugins of
>> > > > the thread support it properly while cronned.
>> > > > Difference is the scope of the checks: CVE only, all deps, plugins
>> and
>> > code
>> > > > (which is where most people don't like since it is trivial to have
>> > false
>> > > > positive and dependabot falls there).
>> > > >
>> > > > I agree CVE are a crucial topic but dependabot is NOT done for them,
>> > it is
>> > > > done for dependencies as a whole and is full of bugs so until it is
>> > refined
>> > > > to be more relevant and bulked differently (maybe *1* mail a week)
>> > then it
>> > > > is not an option for an everyday work IMHO.
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau  |  Blog
>> > > >  | Old Blog
>> > > >  | Github <
>> > https://github.com/rmannibucau> |
>> > > > LinkedIn  | Book
>> > > > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> > > >
>> > > >
>> > > >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory 
>> a
>> > > >> écrit :
>> > > >>
>> > > >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
>> > > >>>
>> > > >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory <
>> garydgreg...@gmail.com>
>> > > >> wrote:
>> > > 
>> > >  One critical feature is that dependabot does all the builds for
>> you
>> > on
>> > >  GitHub Actions, this is an enormous time and resource saver!
>> > > >>>
>> > > >>> Not at all.
>> > > >>> Just the reverse.
>> > > >>>
>> > > >>> It does NOT save resources, because it runs builds for updates
>> that
>> > > >>> are not necessary at that point in time (or ever, in some cases).
>> > > >>>
>> > > >>> Nor does it same time, because the the noise that it generates.
>> > > >>>
>> > > >>>
>> > > >>
>> > > >>> Please stop pretending that Dependabot does things it does not
>> (and
>> > > >>> likely cannot) do.
>> > > >>>
>> > > >>
>> > > >> Oh, boy, Sebb, it feels like you are purposely misunderstanding my
>> > POV.
>> > > >> It's as simple as I stated:
>> > > >>
>> > > >> If Dependabot detects that a new version of a dependency is
>> available,
>> > > >> creates a branch, runs a build, tells me the result and I have a
>> PR I
>> > can
>> > > >> merge, *that is all work and time *I* do not have to do manually!
>> Why
>> > is
>> > > >> that so hard to understand?*
>> > > >>
>> > 

Re: can we get rid of dependabot?

[Matt Benson]

On Wed, Dec 29, 2021, 9:21 AM Mark Thomas  wrote:

> On 29/12/2021 15:04, Gary Gregory wrote:
> > On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins  wrote:
> >
> >> Why not just run dependabot weekly. We move slowly enough that weekly
> >> currently works. Until we can get more hands on the project, slower
> comms
> >> are indeed reasonable…right?
> >>
> >
> > I would be OK with it once a week.
>
> I think the improvement resulting from moving to once a week will be
> minimal.
>
> I get the desire to keep things up to date but the way dependabot is
> currently working creates a lot of traffic on both issues@ and commits@
> That noise makes it much harder to follow any other activity that might
> be happening in the project. I am finding it a lot more effort to keep
> track of the Commons projects I am interested in.
>
> Most commons libraries have very few "real" dependencies. Most of the
> dependencies are there to support testing or building. I would argue
> that updates to test/build libraries are far less critical and low risk
> to update en masse just before a release.
>
> I may look at applying local filters in the short term but that strikes
> me very much as fixing the symptom rather than the cause and I don't
> think it is efficient for every subscriber to have to do this if there
> is an approach available that addresses the root cause.
>
> As an aside, we also need to keep repeatable builds in mind. Simply
> defining a version dependency as "latest" (or anything other than an
> explicit version) is going to be problematic.
>
> So, is there a way we could do something like the following with any
> combination of dependabot and/or Versions Maven plugin and/or something
> else?
>
> - dependabot like behaviour (daily check, separate PR) for dependencies
>that are used (required or optional) at runtime
>
> - a weekly (or even monthly?) check for test libraries, build tools etc.
>(i.e. everything that isn't a runtime dependency) that provides,
>ideally, a single PR with one commit per update
>
> Emphasis on the "something like" the above.
>

To jump into the discussion, I think these are sensible and constructive
suggestions.

Matt

Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

@Gary thing is it is not one email per period but a much email as upgrades
per period with dependabot, there is no bulk email feature

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 29 déc. 2021 à 16:27, Gary Gregory  a
écrit :

> On Wed, Dec 29, 2021 at 9:45 AM sebb  wrote:
>
> > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins  wrote:
> > >
> > > Why not just run dependabot weekly. We move slowly enough that weekly
> > currently works. Until we can get more hands on the project, slower comms
> > are indeed reasonable…right?
> >
> > Weekly runs won't reduce the number of emails, except where a single
> > dependency has been updated twice in a week.
> >
>
> I'm baffled by your reply: If I get one email a day for a week for a new
> dependency version, that's 7 emails. If I get one email a week for a
> dependency, let me see..., that's one a week. So it's seven times LESS.
>
> Gary
>
> >
> > I don't see how it is possible to reduce the noise from dependabot.
> >
> > > -Rob
> > >
> > > > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> > > >
> > > > Saving dev/human resources is about having a CI, all mentionned
> > plugins of
> > > > the thread support it properly while cronned.
> > > > Difference is the scope of the checks: CVE only, all deps, plugins
> and
> > code
> > > > (which is where most people don't like since it is trivial to have
> > false
> > > > positive and dependabot falls there).
> > > >
> > > > I agree CVE are a crucial topic but dependabot is NOT done for them,
> > it is
> > > > done for dependencies as a whole and is full of bugs so until it is
> > refined
> > > > to be more relevant and bulked differently (maybe *1* mail a week)
> > then it
> > > > is not an option for an everyday work IMHO.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > > >
> > > >
> > > >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory 
> a
> > > >> écrit :
> > > >>
> > > >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> > > >>>
> > > >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory  >
> > > >> wrote:
> > > 
> > >  One critical feature is that dependabot does all the builds for
> you
> > on
> > >  GitHub Actions, this is an enormous time and resource saver!
> > > >>>
> > > >>> Not at all.
> > > >>> Just the reverse.
> > > >>>
> > > >>> It does NOT save resources, because it runs builds for updates that
> > > >>> are not necessary at that point in time (or ever, in some cases).
> > > >>>
> > > >>> Nor does it same time, because the the noise that it generates.
> > > >>>
> > > >>>
> > > >>
> > > >>> Please stop pretending that Dependabot does things it does not (and
> > > >>> likely cannot) do.
> > > >>>
> > > >>
> > > >> Oh, boy, Sebb, it feels like you are purposely misunderstanding my
> > POV.
> > > >> It's as simple as I stated:
> > > >>
> > > >> If Dependabot detects that a new version of a dependency is
> available,
> > > >> creates a branch, runs a build, tells me the result and I have a PR
> I
> > can
> > > >> merge, *that is all work and time *I* do not have to do manually!
> Why
> > is
> > > >> that so hard to understand?*
> > > >>
> > > >> Gary
> > > >>
> > > >>
> > >  Gary
> > > 
> > >  On Wed, Dec 29, 2021, 08:51 Rob Tompkins 
> > wrote:
> > > 
> > > >
> > > >
> > > >> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > > >>> rmannibu...@gmail.com>
> > > > wrote:
> > > >>
> > > >> @Rob: dependabot is mainly about dependencies upgrades and it
> is
> > > >>> also
> > > > why
> > > >> it is so chatty and has so much false positives.
> > > >
> > > > Yes, I am well aware. But I do not see how a robot telling you to
> > > >>> simply
> > > > upgrade is a problem?
> > > >
> > > > Maybe I’m missing something but my impression is that’s what
> > > >> dependabot
> > > > does right? Tell you you need to upgrade?
> > > >
> > > > -Rob
> > > >
> > > >> If you want to focus on
> > > >> CVE then setting up on the CI
> > > >> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> > > >> more
> > > >> efficient and accurate (basically when it fails you must act) so
> > > > dependabot
> > > >> is a great reporting tool for managers but not to work on an
> > > >> everyday
> > > > basis
> > > >> IMHO until it is

Re: can we get rid of dependabot?

[Gary Gregory]

On Wed, Dec 29, 2021 at 9:45 AM sebb  wrote:

> On Wed, 29 Dec 2021 at 14:36, Rob Tompkins  wrote:
> >
> > Why not just run dependabot weekly. We move slowly enough that weekly
> currently works. Until we can get more hands on the project, slower comms
> are indeed reasonable…right?
>
> Weekly runs won't reduce the number of emails, except where a single
> dependency has been updated twice in a week.
>

I'm baffled by your reply: If I get one email a day for a week for a new
dependency version, that's 7 emails. If I get one email a week for a
dependency, let me see..., that's one a week. So it's seven times LESS.

Gary

>
> I don't see how it is possible to reduce the noise from dependabot.
>
> > -Rob
> >
> > > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau 
> wrote:
> > >
> > > Saving dev/human resources is about having a CI, all mentionned
> plugins of
> > > the thread support it properly while cronned.
> > > Difference is the scope of the checks: CVE only, all deps, plugins and
> code
> > > (which is where most people don't like since it is trivial to have
> false
> > > positive and dependabot falls there).
> > >
> > > I agree CVE are a crucial topic but dependabot is NOT done for them,
> it is
> > > done for dependencies as a whole and is full of bugs so until it is
> refined
> > > to be more relevant and bulked differently (maybe *1* mail a week)
> then it
> > > is not an option for an everyday work IMHO.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> > >
> > >
> > >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory  a
> > >> écrit :
> > >>
> > >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> > >>>
> > >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> > >> wrote:
> > 
> >  One critical feature is that dependabot does all the builds for you
> on
> >  GitHub Actions, this is an enormous time and resource saver!
> > >>>
> > >>> Not at all.
> > >>> Just the reverse.
> > >>>
> > >>> It does NOT save resources, because it runs builds for updates that
> > >>> are not necessary at that point in time (or ever, in some cases).
> > >>>
> > >>> Nor does it same time, because the the noise that it generates.
> > >>>
> > >>>
> > >>
> > >>> Please stop pretending that Dependabot does things it does not (and
> > >>> likely cannot) do.
> > >>>
> > >>
> > >> Oh, boy, Sebb, it feels like you are purposely misunderstanding my
> POV.
> > >> It's as simple as I stated:
> > >>
> > >> If Dependabot detects that a new version of a dependency is available,
> > >> creates a branch, runs a build, tells me the result and I have a PR I
> can
> > >> merge, *that is all work and time *I* do not have to do manually! Why
> is
> > >> that so hard to understand?*
> > >>
> > >> Gary
> > >>
> > >>
> >  Gary
> > 
> >  On Wed, Dec 29, 2021, 08:51 Rob Tompkins 
> wrote:
> > 
> > >
> > >
> > >> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > >>> rmannibu...@gmail.com>
> > > wrote:
> > >>
> > >> @Rob: dependabot is mainly about dependencies upgrades and it is
> > >>> also
> > > why
> > >> it is so chatty and has so much false positives.
> > >
> > > Yes, I am well aware. But I do not see how a robot telling you to
> > >>> simply
> > > upgrade is a problem?
> > >
> > > Maybe I’m missing something but my impression is that’s what
> > >> dependabot
> > > does right? Tell you you need to upgrade?
> > >
> > > -Rob
> > >
> > >> If you want to focus on
> > >> CVE then setting up on the CI
> > >> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> > >> more
> > >> efficient and accurate (basically when it fails you must act) so
> > > dependabot
> > >> is a great reporting tool for managers but not to work on an
> > >> everyday
> > > basis
> > >> IMHO until it is very finely configure but commons is far to need
> > >> so
> > >>> much
> > >> investment since there already have solutions for everything
> needed
> > >>> IMHO.
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau  |  Blog
> > >>  | Old Blog
> > >>  | Github <
> > > https://github.com/rmannibucau> |
> > >> LinkedIn  | Book
> > >> <
> > >
> > >>>
> > >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>
> > >>
> > >>
> > >>> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins 
> a
> > > écrit :
> > >>>
> > >>> Guys. I think dependabot is our greatest advantage in the work
> > >>> aga

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

@Rob: not sure dependabot would get commits permissions anytime soon, it is
really an automotion thing on one side - we already had since years before
dependabot was a thing BTW - and it would be a poor committer on another
side, since it does changes without validating them or reviewing its impact
in the downstream projects - once again you get a lot of broken PR with
dependabot, I can see commons is not that affected because the dependencies
of commons are light in general but look any other project, it is pure
noise and a good way to break the project (incompatibility with a
dependency, broken OSGi metada, upgrade making a change at compile time -
bytecode breaking change which is invisible with any test suite until you
use compare with previous version - clirr or alike + test, plus it would
enable to use an up to date API when you need to support more so you can
break your consumers - upgrade junit5 to 5.8 and start using 5.8 API when
you must support users relying on junit 5.6 for ex). So the question is
100% the ROI. Dependabot doing a lot of noise and enforcing a lot of work -
if not ignored - it costs a lot whereas dependency upgrades and CVE
management is very very cheap in a project life, even for big ones like
Apache TomEE, so don't think it can be justified as of today.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 29 déc. 2021 à 16:10, Rob Tompkins  a écrit :

> Guys….let us blind our eyes to the source. We are taking about kicking our
> most excited contributor. Are we not? If dependabot were a person they
> would likely have gotten commit rights and be in the PMC. Granted, they’d
> have taken some advice and slowed down a bit and maybe with some steering
> we can accomplish just that.
>
> My last penny,
> -Rob
>
> > On Dec 29, 2021, at 9:53 AM, Gary Gregory 
> wrote:
> >
> > On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
> >
> >>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory 
> wrote:
> >>>
>  On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> >>>
>  On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> >> wrote:
> >
> > One critical feature is that dependabot does all the builds for you
> >> on
> > GitHub Actions, this is an enormous time and resource saver!
> 
>  Not at all.
>  Just the reverse.
> 
>  It does NOT save resources, because it runs builds for updates that
>  are not necessary at that point in time (or ever, in some cases).
> 
>  Nor does it same time, because the the noise that it generates.
> 
> 
> >>>
>  Please stop pretending that Dependabot does things it does not (and
>  likely cannot) do.
> 
> >>>
> >>> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> >>> It's as simple as I stated:
> >>>
> >>> If Dependabot detects that a new version of a dependency is available,
> >>> creates a branch, runs a build, tells me the result and I have a PR I
> can
> >>> merge, *that is all work and time *I* do not have to do manually! Why
> is
> >>> that so hard to understand?*
> >>
> >> Of course I understand that.
> >>
> >
> > Phew! :-)
> >
> >>
> >> However, just because a new version is available does NOT mean that it
> >> has to be updated there and then.
> >> Sometimes it never needs to be updated.
> >>
> >
> > You can't know if you need to make a decision unless someone asks you to
> > make it. I don't know out of thin air that a new version is available.
> >
> >
> >>
> >> Changes to dependencies occur much more frequently than component
> releases.
> >> So often there will be several mails for the same dependency.
> >>
> >> In the past, the approach was to check for new (and useful) updates
> >> shortly before a release.
> >>
> >
> > That must have been before my time and it seems like a horrible idea: The
> > software is stable after a few months of activity and it's time to make a
> > release, so the day before a release, you change all the dependencies,
> and
> > cross your fingers? Yikes!
> >
> >
> >> Generally all the versions would be updated at the same time, instead
> >> of individually.
> >>
> >
> > Not here, if update 10 dependencies and a build fails, then what? I go
> back
> > to square one and update each, one at a time, until I find the culprit,
> > which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> > for components like VFS, Configuration, and others.
> >
> > Gary
> >
> >
> >>> Gary
> >>>
> >>>
> > Gary
> >
> > On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> >
> >>
> >>
> >>> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
>  rmannibu...@gmail.com>
> >> wrote:
> >>>
> >>> @Rob: dependabot is mainly about dependencies up

Re: can we get rid of dependabot?

[Mark Thomas]

On 29/12/2021 15:04, Gary Gregory wrote:

On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins  wrote:


Why not just run dependabot weekly. We move slowly enough that weekly
currently works. Until we can get more hands on the project, slower comms
are indeed reasonable…right?



I would be OK with it once a week.


I think the improvement resulting from moving to once a week will be 
minimal.


I get the desire to keep things up to date but the way dependabot is 
currently working creates a lot of traffic on both issues@ and commits@
That noise makes it much harder to follow any other activity that might 
be happening in the project. I am finding it a lot more effort to keep 
track of the Commons projects I am interested in.


Most commons libraries have very few "real" dependencies. Most of the 
dependencies are there to support testing or building. I would argue 
that updates to test/build libraries are far less critical and low risk 
to update en masse just before a release.


I may look at applying local filters in the short term but that strikes 
me very much as fixing the symptom rather than the cause and I don't 
think it is efficient for every subscriber to have to do this if there 
is an approach available that addresses the root cause.


As an aside, we also need to keep repeatable builds in mind. Simply 
defining a version dependency as "latest" (or anything other than an 
explicit version) is going to be problematic.


So, is there a way we could do something like the following with any 
combination of dependabot and/or Versions Maven plugin and/or something 
else?


- dependabot like behaviour (daily check, separate PR) for dependencies
  that are used (required or optional) at runtime

- a weekly (or even monthly?) check for test libraries, build tools etc.
  (i.e. everything that isn't a runtime dependency) that provides,
  ideally, a single PR with one commit per update

Emphasis on the "something like" the above.

Mark

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

Re: can we get rid of dependabot?

[Rob Tompkins]

Guys….let us blind our eyes to the source. We are taking about kicking our most 
excited contributor. Are we not? If dependabot were a person they would likely 
have gotten commit rights and be in the PMC. Granted, they’d have taken some 
advice and slowed down a bit and maybe with some steering we can accomplish 
just that. 

My last penny,
-Rob

> On Dec 29, 2021, at 9:53 AM, Gary Gregory  wrote:
> 
> On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:
> 
>>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:
>>> 
 On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
>>> 
 On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
>> wrote:
> 
> One critical feature is that dependabot does all the builds for you
>> on
> GitHub Actions, this is an enormous time and resource saver!
 
 Not at all.
 Just the reverse.
 
 It does NOT save resources, because it runs builds for updates that
 are not necessary at that point in time (or ever, in some cases).
 
 Nor does it same time, because the the noise that it generates.
 
 
>>> 
 Please stop pretending that Dependabot does things it does not (and
 likely cannot) do.
 
>>> 
>>> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
>>> It's as simple as I stated:
>>> 
>>> If Dependabot detects that a new version of a dependency is available,
>>> creates a branch, runs a build, tells me the result and I have a PR I can
>>> merge, *that is all work and time *I* do not have to do manually! Why is
>>> that so hard to understand?*
>> 
>> Of course I understand that.
>> 
> 
> Phew! :-)
> 
>> 
>> However, just because a new version is available does NOT mean that it
>> has to be updated there and then.
>> Sometimes it never needs to be updated.
>> 
> 
> You can't know if you need to make a decision unless someone asks you to
> make it. I don't know out of thin air that a new version is available.
> 
> 
>> 
>> Changes to dependencies occur much more frequently than component releases.
>> So often there will be several mails for the same dependency.
>> 
>> In the past, the approach was to check for new (and useful) updates
>> shortly before a release.
>> 
> 
> That must have been before my time and it seems like a horrible idea: The
> software is stable after a few months of activity and it's time to make a
> release, so the day before a release, you change all the dependencies, and
> cross your fingers? Yikes!
> 
> 
>> Generally all the versions would be updated at the same time, instead
>> of individually.
>> 
> 
> Not here, if update 10 dependencies and a build fails, then what? I go back
> to square one and update each, one at a time, until I find the culprit,
> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> for components like VFS, Configuration, and others.
> 
> Gary
> 
> 
>>> Gary
>>> 
>>> 
> Gary
> 
> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> 
>> 
>> 
>>> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
 rmannibu...@gmail.com>
>> wrote:
>>> 
>>> @Rob: dependabot is mainly about dependencies upgrades and it is
 also
>> why
>>> it is so chatty and has so much false positives.
>> 
>> Yes, I am well aware. But I do not see how a robot telling you to
 simply
>> upgrade is a problem?
>> 
>> Maybe I’m missing something but my impression is that’s what
>> dependabot
>> does right? Tell you you need to upgrade?
>> 
>> -Rob
>> 
>>> If you want to focus on
>>> CVE then setting up on the CI
>>> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
>> more
>>> efficient and accurate (basically when it fails you must act) so
>> dependabot
>>> is a great reporting tool for managers but not to work on an
>> everyday
>> basis
>>> IMHO until it is very finely configure but commons is far to
>> need so
 much
>>> investment since there already have solutions for everything
>> needed
 IMHO.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> 
 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
 Le mer. 29 déc. 2021 à 14:39, Rob Tompkins 
>> a
>> écrit :
 
 Guys. I think dependabot is our greatest advantage in the work
 against
 security problems. I know she has her failings and is chatty.
>> But, I
>> think
 we should open a line of thinking about how best she can help.
 
 The reason she’s a pain in the ass is that we don’t have enough
 hands on
 the project making it better. I know I would help more, but I
>> have
 to

Re: can we get rid of dependabot?

[Gary Gregory]

On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins  wrote:

> Why not just run dependabot weekly. We move slowly enough that weekly
> currently works. Until we can get more hands on the project, slower comms
> are indeed reasonable…right?
>

I would be OK with it once a week.

Gary


>
> -Rob
>
> > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau 
> wrote:
> >
> > Saving dev/human resources is about having a CI, all mentionned plugins
> of
> > the thread support it properly while cronned.
> > Difference is the scope of the checks: CVE only, all deps, plugins and
> code
> > (which is where most people don't like since it is trivial to have false
> > positive and dependabot falls there).
> >
> > I agree CVE are a crucial topic but dependabot is NOT done for them, it
> is
> > done for dependencies as a whole and is full of bugs so until it is
> refined
> > to be more relevant and bulked differently (maybe *1* mail a week) then
> it
> > is not an option for an everyday work IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory  a
> >> écrit :
> >>
> >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> >>>
> >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> >> wrote:
> 
>  One critical feature is that dependabot does all the builds for you on
>  GitHub Actions, this is an enormous time and resource saver!
> >>>
> >>> Not at all.
> >>> Just the reverse.
> >>>
> >>> It does NOT save resources, because it runs builds for updates that
> >>> are not necessary at that point in time (or ever, in some cases).
> >>>
> >>> Nor does it same time, because the the noise that it generates.
> >>>
> >>>
> >>
> >>> Please stop pretending that Dependabot does things it does not (and
> >>> likely cannot) do.
> >>>
> >>
> >> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> >> It's as simple as I stated:
> >>
> >> If Dependabot detects that a new version of a dependency is available,
> >> creates a branch, runs a build, tells me the result and I have a PR I
> can
> >> merge, *that is all work and time *I* do not have to do manually! Why is
> >> that so hard to understand?*
> >>
> >> Gary
> >>
> >>
>  Gary
> 
>  On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> 
> >
> >
> >> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>
> > wrote:
> >>
> >> @Rob: dependabot is mainly about dependencies upgrades and it is
> >>> also
> > why
> >> it is so chatty and has so much false positives.
> >
> > Yes, I am well aware. But I do not see how a robot telling you to
> >>> simply
> > upgrade is a problem?
> >
> > Maybe I’m missing something but my impression is that’s what
> >> dependabot
> > does right? Tell you you need to upgrade?
> >
> > -Rob
> >
> >> If you want to focus on
> >> CVE then setting up on the CI
> >> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> >> more
> >> efficient and accurate (basically when it fails you must act) so
> > dependabot
> >> is a great reporting tool for managers but not to work on an
> >> everyday
> > basis
> >> IMHO until it is very finely configure but commons is far to need
> >> so
> >>> much
> >> investment since there already have solutions for everything needed
> >>> IMHO.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> > https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
> >>
> >>
> >>> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> > écrit :
> >>>
> >>> Guys. I think dependabot is our greatest advantage in the work
> >>> against
> >>> security problems. I know she has her failings and is chatty.
> >> But, I
> > think
> >>> we should open a line of thinking about how best she can help.
> >>>
> >>> The reason she’s a pain in the ass is that we don’t have enough
> >>> hands on
> >>> the project making it better. I know I would help more, but I have
> >>> to
> > keep
> >>> up with my father who’s a quadriplegic as well as a currently
> >>> failing
> >>> marriage.
> >>>
> >>> The answer is that we need more hands on the project. I wish I
> >>> could be
> >>> those hands but time and priorities keep me chained.
> >>>
> >>> Cheers,

Re: can we get rid of dependabot?

[Gary Gregory]

On Wed, Dec 29, 2021 at 9:42 AM sebb  wrote:

> On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:
> >
> > On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> >
> > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> wrote:
> > > >
> > > > One critical feature is that dependabot does all the builds for you
> on
> > > > GitHub Actions, this is an enormous time and resource saver!
> > >
> > > Not at all.
> > > Just the reverse.
> > >
> > > It does NOT save resources, because it runs builds for updates that
> > > are not necessary at that point in time (or ever, in some cases).
> > >
> > > Nor does it same time, because the the noise that it generates.
> > >
> > >
> >
> > > Please stop pretending that Dependabot does things it does not (and
> > > likely cannot) do.
> > >
> >
> > Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> > It's as simple as I stated:
> >
> > If Dependabot detects that a new version of a dependency is available,
> > creates a branch, runs a build, tells me the result and I have a PR I can
> > merge, *that is all work and time *I* do not have to do manually! Why is
> > that so hard to understand?*
>
> Of course I understand that.
>

Phew! :-)

>
> However, just because a new version is available does NOT mean that it
> has to be updated there and then.
> Sometimes it never needs to be updated.
>

You can't know if you need to make a decision unless someone asks you to
make it. I don't know out of thin air that a new version is available.


>
> Changes to dependencies occur much more frequently than component releases.
> So often there will be several mails for the same dependency.
>
> In the past, the approach was to check for new (and useful) updates
> shortly before a release.
>

That must have been before my time and it seems like a horrible idea: The
software is stable after a few months of activity and it's time to make a
release, so the day before a release, you change all the dependencies, and
cross your fingers? Yikes!


> Generally all the versions would be updated at the same time, instead
> of individually.
>

Not here, if update 10 dependencies and a build fails, then what? I go back
to square one and update each, one at a time, until I find the culprit,
which to me is a waste of time. BTW, 10 dependencies is not unreasonable
for components like VFS, Configuration, and others.

Gary


> > Gary
> >
> >
> > > > Gary
> > > >
> > > > On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> > > >
> > > > >
> > > > >
> > > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > @Rob: dependabot is mainly about dependencies upgrades and it is
> > > also
> > > > > why
> > > > > > it is so chatty and has so much false positives.
> > > > >
> > > > > Yes, I am well aware. But I do not see how a robot telling you to
> > > simply
> > > > > upgrade is a problem?
> > > > >
> > > > > Maybe I’m missing something but my impression is that’s what
> dependabot
> > > > > does right? Tell you you need to upgrade?
> > > > >
> > > > > -Rob
> > > > >
> > > > > > If you want to focus on
> > > > > > CVE then setting up on the CI
> > > > > > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> more
> > > > > > efficient and accurate (basically when it fails you must act) so
> > > > > dependabot
> > > > > > is a great reporting tool for managers but not to work on an
> everyday
> > > > > basis
> > > > > > IMHO until it is very finely configure but commons is far to
> need so
> > > much
> > > > > > investment since there already have solutions for everything
> needed
> > > IMHO.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Old Blog
> > > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn  | Book
> > > > > > <
> > > > >
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > > >
> > > > > >
> > > > > >> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins 
> a
> > > > > écrit :
> > > > > >>
> > > > > >> Guys. I think dependabot is our greatest advantage in the work
> > > against
> > > > > >> security problems. I know she has her failings and is chatty.
> But, I
> > > > > think
> > > > > >> we should open a line of thinking about how best she can help.
> > > > > >>
> > > > > >> The reason she’s a pain in the ass is that we don’t have enough
> > > hands on
> > > > > >> the project making it better. I know I would help more, but I
> have
> > > to
> > > > > keep
> > > > > >> up with my father who’s a quadriplegic as well as a currently
> > > failing
> > > > > >> marriage.
> > > > > >>
> > > > > >> The answer is that we need more hands on the project. I wish I
> > > could be
> > > > > >> those hands but time and priorities keep me chained.
> > > > > >>
> > > > > >> 

Re: can we get rid of dependabot?

[sebb]

On Wed, 29 Dec 2021 at 14:36, Rob Tompkins  wrote:
>
> Why not just run dependabot weekly. We move slowly enough that weekly 
> currently works. Until we can get more hands on the project, slower comms are 
> indeed reasonable…right?

Weekly runs won't reduce the number of emails, except where a single
dependency has been updated twice in a week.

I don't see how it is possible to reduce the noise from dependabot.

> -Rob
>
> > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau  
> > wrote:
> >
> > Saving dev/human resources is about having a CI, all mentionned plugins of
> > the thread support it properly while cronned.
> > Difference is the scope of the checks: CVE only, all deps, plugins and code
> > (which is where most people don't like since it is trivial to have false
> > positive and dependabot falls there).
> >
> > I agree CVE are a crucial topic but dependabot is NOT done for them, it is
> > done for dependencies as a whole and is full of bugs so until it is refined
> > to be more relevant and bulked differently (maybe *1* mail a week) then it
> > is not an option for an everyday work IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github 
> >  |
> > LinkedIn  | Book
> > 
> >
> >
> >> Le mer. 29 déc. 2021 à 15:18, Gary Gregory  a
> >> écrit :
> >>
> >>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
> >>>
> >>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> >> wrote:
> 
>  One critical feature is that dependabot does all the builds for you on
>  GitHub Actions, this is an enormous time and resource saver!
> >>>
> >>> Not at all.
> >>> Just the reverse.
> >>>
> >>> It does NOT save resources, because it runs builds for updates that
> >>> are not necessary at that point in time (or ever, in some cases).
> >>>
> >>> Nor does it same time, because the the noise that it generates.
> >>>
> >>>
> >>
> >>> Please stop pretending that Dependabot does things it does not (and
> >>> likely cannot) do.
> >>>
> >>
> >> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> >> It's as simple as I stated:
> >>
> >> If Dependabot detects that a new version of a dependency is available,
> >> creates a branch, runs a build, tells me the result and I have a PR I can
> >> merge, *that is all work and time *I* do not have to do manually! Why is
> >> that so hard to understand?*
> >>
> >> Gary
> >>
> >>
>  Gary
> 
>  On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> 
> >
> >
> >> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>
> > wrote:
> >>
> >> @Rob: dependabot is mainly about dependencies upgrades and it is
> >>> also
> > why
> >> it is so chatty and has so much false positives.
> >
> > Yes, I am well aware. But I do not see how a robot telling you to
> >>> simply
> > upgrade is a problem?
> >
> > Maybe I’m missing something but my impression is that’s what
> >> dependabot
> > does right? Tell you you need to upgrade?
> >
> > -Rob
> >
> >> If you want to focus on
> >> CVE then setting up on the CI
> >> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> >> more
> >> efficient and accurate (basically when it fails you must act) so
> > dependabot
> >> is a great reporting tool for managers but not to work on an
> >> everyday
> > basis
> >> IMHO until it is very finely configure but commons is far to need
> >> so
> >>> much
> >> investment since there already have solutions for everything needed
> >>> IMHO.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> > https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >
> >>>
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
> >>
> >>
> >>> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> > écrit :
> >>>
> >>> Guys. I think dependabot is our greatest advantage in the work
> >>> against
> >>> security problems. I know she has her failings and is chatty.
> >> But, I
> > think
> >>> we should open a line of thinking about how best she can help.
> >>>
> >>> The reason she’s a pain in the ass is that we don’t have enough
> >>> hands on
> >>> the project making it better. I know I would help more, but I have
> >>> to
> > keep
> >>> up with my father who’s a quadriplegic as well as a currently
> >>> failing
> >>> marriage.
> >>>
> >>> The answer is that we need more hands on the p

Re: can we get rid of dependabot?

[sebb]

On Wed, 29 Dec 2021 at 14:18, Gary Gregory  wrote:
>
> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
>
> > On Wed, 29 Dec 2021 at 13:54, Gary Gregory  wrote:
> > >
> > > One critical feature is that dependabot does all the builds for you on
> > > GitHub Actions, this is an enormous time and resource saver!
> >
> > Not at all.
> > Just the reverse.
> >
> > It does NOT save resources, because it runs builds for updates that
> > are not necessary at that point in time (or ever, in some cases).
> >
> > Nor does it same time, because the the noise that it generates.
> >
> >
>
> > Please stop pretending that Dependabot does things it does not (and
> > likely cannot) do.
> >
>
> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> It's as simple as I stated:
>
> If Dependabot detects that a new version of a dependency is available,
> creates a branch, runs a build, tells me the result and I have a PR I can
> merge, *that is all work and time *I* do not have to do manually! Why is
> that so hard to understand?*

Of course I understand that.

However, just because a new version is available does NOT mean that it
has to be updated there and then.
Sometimes it never needs to be updated.

Changes to dependencies occur much more frequently than component releases.
So often there will be several mails for the same dependency.

In the past, the approach was to check for new (and useful) updates
shortly before a release.
Generally all the versions would be updated at the same time, instead
of individually.

> Gary
>
>
> > > Gary
> > >
> > > On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> > >
> > > >
> > > >
> > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > > wrote:
> > > > >
> > > > > @Rob: dependabot is mainly about dependencies upgrades and it is
> > also
> > > > why
> > > > > it is so chatty and has so much false positives.
> > > >
> > > > Yes, I am well aware. But I do not see how a robot telling you to
> > simply
> > > > upgrade is a problem?
> > > >
> > > > Maybe I’m missing something but my impression is that’s what dependabot
> > > > does right? Tell you you need to upgrade?
> > > >
> > > > -Rob
> > > >
> > > > > If you want to focus on
> > > > > CVE then setting up on the CI
> > > > > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
> > > > > efficient and accurate (basically when it fails you must act) so
> > > > dependabot
> > > > > is a great reporting tool for managers but not to work on an everyday
> > > > basis
> > > > > IMHO until it is very finely configure but commons is far to need so
> > much
> > > > > investment since there already have solutions for everything needed
> > IMHO.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > > >
> > > > >
> > > > >> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> > > > écrit :
> > > > >>
> > > > >> Guys. I think dependabot is our greatest advantage in the work
> > against
> > > > >> security problems. I know she has her failings and is chatty. But, I
> > > > think
> > > > >> we should open a line of thinking about how best she can help.
> > > > >>
> > > > >> The reason she’s a pain in the ass is that we don’t have enough
> > hands on
> > > > >> the project making it better. I know I would help more, but I have
> > to
> > > > keep
> > > > >> up with my father who’s a quadriplegic as well as a currently
> > failing
> > > > >> marriage.
> > > > >>
> > > > >> The answer is that we need more hands on the project. I wish I
> > could be
> > > > >> those hands but time and priorities keep me chained.
> > > > >>
> > > > >> Cheers,
> > > > >> -Rob
> > > > >>
> > > > >>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski  > >
> > > > >> wrote:
> > > > >>>
> > > > >>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a
> > écrit
> > > > :
> > > > 
> > > >  +1
> > > >  Thank you, Phil. This thing is a P.I.T.A.
> > > > >>>
> > > > >>> In effect, from day one:
> > > > >>>  https://markmail.org/message/2vutc4p3b3eqv73f
> > > > >>>
> > > > >>> Basically, the argument is that
> > > > >>> * the (dependabot) feature is too important to be disabled
> > > > >>> * the annoyed people should filter out those mails (which I
> > > > >>> did since no one at the time supported that they be diverted
> > > > >>> to another ML).
> > > > >>> Did anything change since then?
> > > > >>> [Or do we eventually question the general anomaly that code
> > > > >>> discussions have been almost completely off-loaded to GH?]
> > > > >>>
> > > > >>> Gilles
> > > > >>>
> > > > 
> > > > >> Am 28.12.2021 um 19:20 schrieb Phil Steitz 

Re: can we get rid of dependabot?

[Rob Tompkins]

Why not just run dependabot weekly. We move slowly enough that weekly currently 
works. Until we can get more hands on the project, slower comms are indeed 
reasonable…right?

-Rob

> On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau  wrote:
> 
> Saving dev/human resources is about having a CI, all mentionned plugins of
> the thread support it properly while cronned.
> Difference is the scope of the checks: CVE only, all deps, plugins and code
> (which is where most people don't like since it is trivial to have false
> positive and dependabot falls there).
> 
> I agree CVE are a crucial topic but dependabot is NOT done for them, it is
> done for dependencies as a whole and is full of bugs so until it is refined
> to be more relevant and bulked differently (maybe *1* mail a week) then it
> is not an option for an everyday work IMHO.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
>> Le mer. 29 déc. 2021 à 15:18, Gary Gregory  a
>> écrit :
>> 
>>> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
>>> 
>>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
>> wrote:
 
 One critical feature is that dependabot does all the builds for you on
 GitHub Actions, this is an enormous time and resource saver!
>>> 
>>> Not at all.
>>> Just the reverse.
>>> 
>>> It does NOT save resources, because it runs builds for updates that
>>> are not necessary at that point in time (or ever, in some cases).
>>> 
>>> Nor does it same time, because the the noise that it generates.
>>> 
>>> 
>> 
>>> Please stop pretending that Dependabot does things it does not (and
>>> likely cannot) do.
>>> 
>> 
>> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
>> It's as simple as I stated:
>> 
>> If Dependabot detects that a new version of a dependency is available,
>> creates a branch, runs a build, tells me the result and I have a PR I can
>> merge, *that is all work and time *I* do not have to do manually! Why is
>> that so hard to understand?*
>> 
>> Gary
>> 
>> 
 Gary
 
 On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
 
> 
> 
>> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
> wrote:
>> 
>> @Rob: dependabot is mainly about dependencies upgrades and it is
>>> also
> why
>> it is so chatty and has so much false positives.
> 
> Yes, I am well aware. But I do not see how a robot telling you to
>>> simply
> upgrade is a problem?
> 
> Maybe I’m missing something but my impression is that’s what
>> dependabot
> does right? Tell you you need to upgrade?
> 
> -Rob
> 
>> If you want to focus on
>> CVE then setting up on the CI
>> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
>> more
>> efficient and accurate (basically when it fails you must act) so
> dependabot
>> is a great reporting tool for managers but not to work on an
>> everyday
> basis
>> IMHO until it is very finely configure but commons is far to need
>> so
>>> much
>> investment since there already have solutions for everything needed
>>> IMHO.
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
> 
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> 
>> 
>> 
>>> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> écrit :
>>> 
>>> Guys. I think dependabot is our greatest advantage in the work
>>> against
>>> security problems. I know she has her failings and is chatty.
>> But, I
> think
>>> we should open a line of thinking about how best she can help.
>>> 
>>> The reason she’s a pain in the ass is that we don’t have enough
>>> hands on
>>> the project making it better. I know I would help more, but I have
>>> to
> keep
>>> up with my father who’s a quadriplegic as well as a currently
>>> failing
>>> marriage.
>>> 
>>> The answer is that we need more hands on the project. I wish I
>>> could be
>>> those hands but time and priorities keep me chained.
>>> 
>>> Cheers,
>>> -Rob
>>> 
 On Dec 29, 2021, at 8:26 AM, Gilles Sadowski <
>> gillese...@gmail.com
 
>>> wrote:
 
 Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a
>>> écrit
> :
> 
> +1
> Thank you, Phil. This thing is a P.I.T.A.
 
 In effect, from day one:
 https://markmail.org/mes

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

Saving dev/human resources is about having a CI, all mentionned plugins of
the thread support it properly while cronned.
Difference is the scope of the checks: CVE only, all deps, plugins and code
(which is where most people don't like since it is trivial to have false
positive and dependabot falls there).

I agree CVE are a crucial topic but dependabot is NOT done for them, it is
done for dependencies as a whole and is full of bugs so until it is refined
to be more relevant and bulked differently (maybe *1* mail a week) then it
is not an option for an everyday work IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 29 déc. 2021 à 15:18, Gary Gregory  a
écrit :

> On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:
>
> > On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> wrote:
> > >
> > > One critical feature is that dependabot does all the builds for you on
> > > GitHub Actions, this is an enormous time and resource saver!
> >
> > Not at all.
> > Just the reverse.
> >
> > It does NOT save resources, because it runs builds for updates that
> > are not necessary at that point in time (or ever, in some cases).
> >
> > Nor does it same time, because the the noise that it generates.
> >
> >
>
> > Please stop pretending that Dependabot does things it does not (and
> > likely cannot) do.
> >
>
> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> It's as simple as I stated:
>
> If Dependabot detects that a new version of a dependency is available,
> creates a branch, runs a build, tells me the result and I have a PR I can
> merge, *that is all work and time *I* do not have to do manually! Why is
> that so hard to understand?*
>
> Gary
>
>
> > > Gary
> > >
> > > On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> > >
> > > >
> > > >
> > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > > wrote:
> > > > >
> > > > > @Rob: dependabot is mainly about dependencies upgrades and it is
> > also
> > > > why
> > > > > it is so chatty and has so much false positives.
> > > >
> > > > Yes, I am well aware. But I do not see how a robot telling you to
> > simply
> > > > upgrade is a problem?
> > > >
> > > > Maybe I’m missing something but my impression is that’s what
> dependabot
> > > > does right? Tell you you need to upgrade?
> > > >
> > > > -Rob
> > > >
> > > > > If you want to focus on
> > > > > CVE then setting up on the CI
> > > > > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
> more
> > > > > efficient and accurate (basically when it fails you must act) so
> > > > dependabot
> > > > > is a great reporting tool for managers but not to work on an
> everyday
> > > > basis
> > > > > IMHO until it is very finely configure but commons is far to need
> so
> > much
> > > > > investment since there already have solutions for everything needed
> > IMHO.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > > >
> > > > >
> > > > >> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> > > > écrit :
> > > > >>
> > > > >> Guys. I think dependabot is our greatest advantage in the work
> > against
> > > > >> security problems. I know she has her failings and is chatty.
> But, I
> > > > think
> > > > >> we should open a line of thinking about how best she can help.
> > > > >>
> > > > >> The reason she’s a pain in the ass is that we don’t have enough
> > hands on
> > > > >> the project making it better. I know I would help more, but I have
> > to
> > > > keep
> > > > >> up with my father who’s a quadriplegic as well as a currently
> > failing
> > > > >> marriage.
> > > > >>
> > > > >> The answer is that we need more hands on the project. I wish I
> > could be
> > > > >> those hands but time and priorities keep me chained.
> > > > >>
> > > > >> Cheers,
> > > > >> -Rob
> > > > >>
> > > > >>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski <
> gillese...@gmail.com
> > >
> > > > >> wrote:
> > > > >>>
> > > > >>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a
> > écrit
> > > > :
> > > > 
> > > >  +1
> > > >  Thank you, Phil. This thing is a P.I.T.A.
> > > > >>>
> > > > >>> In effect, from day one:
> > > > >>>  https://markmail.org/message/2vutc4p3b3eqv73f
> > > > >>>
> > > > >>> Basically, the argument is that
> > > > >>> * the (dependabot) feature is too important to be disabled
> > > > >>

Re: can we get rid of dependabot?

[Gary Gregory]

On Wed, Dec 29, 2021 at 9:07 AM sebb  wrote:

> On Wed, 29 Dec 2021 at 13:54, Gary Gregory  wrote:
> >
> > One critical feature is that dependabot does all the builds for you on
> > GitHub Actions, this is an enormous time and resource saver!
>
> Not at all.
> Just the reverse.
>
> It does NOT save resources, because it runs builds for updates that
> are not necessary at that point in time (or ever, in some cases).
>
> Nor does it same time, because the the noise that it generates.
>
>

> Please stop pretending that Dependabot does things it does not (and
> likely cannot) do.
>

Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
It's as simple as I stated:

If Dependabot detects that a new version of a dependency is available,
creates a branch, runs a build, tells me the result and I have a PR I can
merge, *that is all work and time *I* do not have to do manually! Why is
that so hard to understand?*

Gary


> > Gary
> >
> > On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
> >
> > >
> > >
> > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > wrote:
> > > >
> > > > @Rob: dependabot is mainly about dependencies upgrades and it is
> also
> > > why
> > > > it is so chatty and has so much false positives.
> > >
> > > Yes, I am well aware. But I do not see how a robot telling you to
> simply
> > > upgrade is a problem?
> > >
> > > Maybe I’m missing something but my impression is that’s what dependabot
> > > does right? Tell you you need to upgrade?
> > >
> > > -Rob
> > >
> > > > If you want to focus on
> > > > CVE then setting up on the CI
> > > > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
> > > > efficient and accurate (basically when it fails you must act) so
> > > dependabot
> > > > is a great reporting tool for managers but not to work on an everyday
> > > basis
> > > > IMHO until it is very finely configure but commons is far to need so
> much
> > > > investment since there already have solutions for everything needed
> IMHO.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > >> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> > > écrit :
> > > >>
> > > >> Guys. I think dependabot is our greatest advantage in the work
> against
> > > >> security problems. I know she has her failings and is chatty. But, I
> > > think
> > > >> we should open a line of thinking about how best she can help.
> > > >>
> > > >> The reason she’s a pain in the ass is that we don’t have enough
> hands on
> > > >> the project making it better. I know I would help more, but I have
> to
> > > keep
> > > >> up with my father who’s a quadriplegic as well as a currently
> failing
> > > >> marriage.
> > > >>
> > > >> The answer is that we need more hands on the project. I wish I
> could be
> > > >> those hands but time and priorities keep me chained.
> > > >>
> > > >> Cheers,
> > > >> -Rob
> > > >>
> > > >>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski  >
> > > >> wrote:
> > > >>>
> > > >>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a
> écrit
> > > :
> > > 
> > >  +1
> > >  Thank you, Phil. This thing is a P.I.T.A.
> > > >>>
> > > >>> In effect, from day one:
> > > >>>  https://markmail.org/message/2vutc4p3b3eqv73f
> > > >>>
> > > >>> Basically, the argument is that
> > > >>> * the (dependabot) feature is too important to be disabled
> > > >>> * the annoyed people should filter out those mails (which I
> > > >>> did since no one at the time supported that they be diverted
> > > >>> to another ML).
> > > >>> Did anything change since then?
> > > >>> [Or do we eventually question the general anomaly that code
> > > >>> discussions have been almost completely off-loaded to GH?]
> > > >>>
> > > >>> Gilles
> > > >>>
> > > 
> > > >> Am 28.12.2021 um 19:20 schrieb Phil Steitz <
> phil.ste...@gmail.com>:
> > > >
> > > > I can no longer effectively monitor commits@ due to the spam
> > > >> generated by this tool.  I am afraid my eyeballs aren't the only
> ones
> > > going
> > > >> missing here and that is a problem much more severe than any value
> > > provided
> > > >> by this tool, IMO.
> > > >
> > > > Phil
> > > 
> > >  Bye, Thomas
> > > >>>
> > > >>>
> -
> > > >>> 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 addit

Re: can we get rid of dependabot?

[sebb]

On Wed, 29 Dec 2021 at 13:54, Gary Gregory  wrote:
>
> One critical feature is that dependabot does all the builds for you on
> GitHub Actions, this is an enormous time and resource saver!

Not at all.
Just the reverse.

It does NOT save resources, because it runs builds for updates that
are not necessary at that point in time (or ever, in some cases).

Nor does it same time, because the the noise that it generates.

Please stop pretending that Dependabot does things it does not (and
likely cannot) do.

> Gary
>
> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
>
> >
> >
> > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau 
> > wrote:
> > >
> > > @Rob: dependabot is mainly about dependencies upgrades and it is also
> > why
> > > it is so chatty and has so much false positives.
> >
> > Yes, I am well aware. But I do not see how a robot telling you to simply
> > upgrade is a problem?
> >
> > Maybe I’m missing something but my impression is that’s what dependabot
> > does right? Tell you you need to upgrade?
> >
> > -Rob
> >
> > > If you want to focus on
> > > CVE then setting up on the CI
> > > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
> > > efficient and accurate (basically when it fails you must act) so
> > dependabot
> > > is a great reporting tool for managers but not to work on an everyday
> > basis
> > > IMHO until it is very finely configure but commons is far to need so much
> > > investment since there already have solutions for everything needed IMHO.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > >> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> > écrit :
> > >>
> > >> Guys. I think dependabot is our greatest advantage in the work against
> > >> security problems. I know she has her failings and is chatty. But, I
> > think
> > >> we should open a line of thinking about how best she can help.
> > >>
> > >> The reason she’s a pain in the ass is that we don’t have enough hands on
> > >> the project making it better. I know I would help more, but I have to
> > keep
> > >> up with my father who’s a quadriplegic as well as a currently failing
> > >> marriage.
> > >>
> > >> The answer is that we need more hands on the project. I wish I could be
> > >> those hands but time and priorities keep me chained.
> > >>
> > >> Cheers,
> > >> -Rob
> > >>
> > >>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski 
> > >> wrote:
> > >>>
> > >>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit
> > :
> > 
> >  +1
> >  Thank you, Phil. This thing is a P.I.T.A.
> > >>>
> > >>> In effect, from day one:
> > >>>  https://markmail.org/message/2vutc4p3b3eqv73f
> > >>>
> > >>> Basically, the argument is that
> > >>> * the (dependabot) feature is too important to be disabled
> > >>> * the annoyed people should filter out those mails (which I
> > >>> did since no one at the time supported that they be diverted
> > >>> to another ML).
> > >>> Did anything change since then?
> > >>> [Or do we eventually question the general anomaly that code
> > >>> discussions have been almost completely off-loaded to GH?]
> > >>>
> > >>> Gilles
> > >>>
> > 
> > >> Am 28.12.2021 um 19:20 schrieb Phil Steitz :
> > >
> > > I can no longer effectively monitor commits@ due to the spam
> > >> generated by this tool.  I am afraid my eyeballs aren't the only ones
> > going
> > >> missing here and that is a problem much more severe than any value
> > provided
> > >> by this tool, IMO.
> > >
> > > Phil
> > 
> >  Bye, Thomas
> > >>>
> > >>> -
> > >>> 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

Re: can we get rid of dependabot?

[Rob Tompkins]

> On Dec 29, 2021, at 8:54 AM, Gary Gregory  wrote:
> 
> One critical feature is that dependabot does all the builds for you on
> GitHub Actions, this is an enormous time and resource saver!
> 

Ding ding ding ding….we have a winner. We just don’t yet know how to implement. 



> Gary
> 
>> On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:
>> 
>> 
>> 
>>> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> @Rob: dependabot is mainly about dependencies upgrades and it is also
>> why
>>> it is so chatty and has so much false positives.
>> 
>> Yes, I am well aware. But I do not see how a robot telling you to simply
>> upgrade is a problem?
>> 
>> Maybe I’m missing something but my impression is that’s what dependabot
>> does right? Tell you you need to upgrade?
>> 
>> -Rob
>> 
>>> If you want to focus on
>>> CVE then setting up on the CI
>>> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
>>> efficient and accurate (basically when it fails you must act) so
>> dependabot
>>> is a great reporting tool for managers but not to work on an everyday
>> basis
>>> IMHO until it is very finely configure but commons is far to need so much
>>> investment since there already have solutions for everything needed IMHO.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
 Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
>> écrit :
 
 Guys. I think dependabot is our greatest advantage in the work against
 security problems. I know she has her failings and is chatty. But, I
>> think
 we should open a line of thinking about how best she can help.
 
 The reason she’s a pain in the ass is that we don’t have enough hands on
 the project making it better. I know I would help more, but I have to
>> keep
 up with my father who’s a quadriplegic as well as a currently failing
 marriage.
 
 The answer is that we need more hands on the project. I wish I could be
 those hands but time and priorities keep me chained.
 
 Cheers,
 -Rob
 
> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski 
 wrote:
> 
> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit
>> :
>> 
>> +1
>> Thank you, Phil. This thing is a P.I.T.A.
> 
> In effect, from day one:
> https://markmail.org/message/2vutc4p3b3eqv73f
> 
> Basically, the argument is that
> * the (dependabot) feature is too important to be disabled
> * the annoyed people should filter out those mails (which I
> did since no one at the time supported that they be diverted
> to another ML).
> Did anything change since then?
> [Or do we eventually question the general anomaly that code
> discussions have been almost completely off-loaded to GH?]
> 
> Gilles
> 
>> 
 Am 28.12.2021 um 19:20 schrieb Phil Steitz :
>>> 
>>> I can no longer effectively monitor commits@ due to the spam
 generated by this tool.  I am afraid my eyeballs aren't the only ones
>> going
 missing here and that is a problem much more severe than any value
>> provided
 by this tool, IMO.
>>> 
>>> Phil
>> 
>> Bye, Thomas
> 
> -
> 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

Re: can we get rid of dependabot?

[Gary Gregory]

One critical feature is that dependabot does all the builds for you on
GitHub Actions, this is an enormous time and resource saver!

Gary

On Wed, Dec 29, 2021, 08:51 Rob Tompkins  wrote:

>
>
> > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau 
> wrote:
> >
> > @Rob: dependabot is mainly about dependencies upgrades and it is also
> why
> > it is so chatty and has so much false positives.
>
> Yes, I am well aware. But I do not see how a robot telling you to simply
> upgrade is a problem?
>
> Maybe I’m missing something but my impression is that’s what dependabot
> does right? Tell you you need to upgrade?
>
> -Rob
>
> > If you want to focus on
> > CVE then setting up on the CI
> > https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
> > efficient and accurate (basically when it fails you must act) so
> dependabot
> > is a great reporting tool for managers but not to work on an everyday
> basis
> > IMHO until it is very finely configure but commons is far to need so much
> > investment since there already have solutions for everything needed IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> >> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a
> écrit :
> >>
> >> Guys. I think dependabot is our greatest advantage in the work against
> >> security problems. I know she has her failings and is chatty. But, I
> think
> >> we should open a line of thinking about how best she can help.
> >>
> >> The reason she’s a pain in the ass is that we don’t have enough hands on
> >> the project making it better. I know I would help more, but I have to
> keep
> >> up with my father who’s a quadriplegic as well as a currently failing
> >> marriage.
> >>
> >> The answer is that we need more hands on the project. I wish I could be
> >> those hands but time and priorities keep me chained.
> >>
> >> Cheers,
> >> -Rob
> >>
> >>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski 
> >> wrote:
> >>>
> >>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit
> :
> 
>  +1
>  Thank you, Phil. This thing is a P.I.T.A.
> >>>
> >>> In effect, from day one:
> >>>  https://markmail.org/message/2vutc4p3b3eqv73f
> >>>
> >>> Basically, the argument is that
> >>> * the (dependabot) feature is too important to be disabled
> >>> * the annoyed people should filter out those mails (which I
> >>> did since no one at the time supported that they be diverted
> >>> to another ML).
> >>> Did anything change since then?
> >>> [Or do we eventually question the general anomaly that code
> >>> discussions have been almost completely off-loaded to GH?]
> >>>
> >>> Gilles
> >>>
> 
> >> Am 28.12.2021 um 19:20 schrieb Phil Steitz :
> >
> > I can no longer effectively monitor commits@ due to the spam
> >> generated by this tool.  I am afraid my eyeballs aren't the only ones
> going
> >> missing here and that is a problem much more severe than any value
> provided
> >> by this tool, IMO.
> >
> > Phil
> 
>  Bye, Thomas
> >>>
> >>> -
> >>> 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
>
>

Re: can we get rid of dependabot?

[Rob Tompkins]

> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau  wrote:
> 
> @Rob: dependabot is mainly about dependencies upgrades and it is also why
> it is so chatty and has so much false positives.

Yes, I am well aware. But I do not see how a robot telling you to simply 
upgrade is a problem?

Maybe I’m missing something but my impression is that’s what dependabot does 
right? Tell you you need to upgrade?

-Rob

> If you want to focus on
> CVE then setting up on the CI
> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
> efficient and accurate (basically when it fails you must act) so dependabot
> is a great reporting tool for managers but not to work on an everyday basis
> IMHO until it is very finely configure but commons is far to need so much
> investment since there already have solutions for everything needed IMHO.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
>> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a écrit :
>> 
>> Guys. I think dependabot is our greatest advantage in the work against
>> security problems. I know she has her failings and is chatty. But, I think
>> we should open a line of thinking about how best she can help.
>> 
>> The reason she’s a pain in the ass is that we don’t have enough hands on
>> the project making it better. I know I would help more, but I have to keep
>> up with my father who’s a quadriplegic as well as a currently failing
>> marriage.
>> 
>> The answer is that we need more hands on the project. I wish I could be
>> those hands but time and priorities keep me chained.
>> 
>> Cheers,
>> -Rob
>> 
>>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski 
>> wrote:
>>> 
>>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit :
 
 +1
 Thank you, Phil. This thing is a P.I.T.A.
>>> 
>>> In effect, from day one:
>>>  https://markmail.org/message/2vutc4p3b3eqv73f
>>> 
>>> Basically, the argument is that
>>> * the (dependabot) feature is too important to be disabled
>>> * the annoyed people should filter out those mails (which I
>>> did since no one at the time supported that they be diverted
>>> to another ML).
>>> Did anything change since then?
>>> [Or do we eventually question the general anomaly that code
>>> discussions have been almost completely off-loaded to GH?]
>>> 
>>> Gilles
>>> 
 
>> Am 28.12.2021 um 19:20 schrieb Phil Steitz :
> 
> I can no longer effectively monitor commits@ due to the spam
>> generated by this tool.  I am afraid my eyeballs aren't the only ones going
>> missing here and that is a problem much more severe than any value provided
>> by this tool, IMO.
> 
> Phil
 
 Bye, Thomas
>>> 
>>> -
>>> 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

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

@Rob: dependabot is mainly about dependencies upgrades and it is also why
it is so chatty and has so much false positives. If you want to focus on
CVE then setting up on the CI
https://sonatype.github.io/ossindex-maven/maven-plugin/ is way more
efficient and accurate (basically when it fails you must act) so dependabot
is a great reporting tool for managers but not to work on an everyday basis
IMHO until it is very finely configure but commons is far to need so much
investment since there already have solutions for everything needed IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 29 déc. 2021 à 14:39, Rob Tompkins  a écrit :

> Guys. I think dependabot is our greatest advantage in the work against
> security problems. I know she has her failings and is chatty. But, I think
> we should open a line of thinking about how best she can help.
>
> The reason she’s a pain in the ass is that we don’t have enough hands on
> the project making it better. I know I would help more, but I have to keep
> up with my father who’s a quadriplegic as well as a currently failing
> marriage.
>
> The answer is that we need more hands on the project. I wish I could be
> those hands but time and priorities keep me chained.
>
> Cheers,
> -Rob
>
> > On Dec 29, 2021, at 8:26 AM, Gilles Sadowski 
> wrote:
> >
> > Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit :
> >>
> >> +1
> >> Thank you, Phil. This thing is a P.I.T.A.
> >
> > In effect, from day one:
> >   https://markmail.org/message/2vutc4p3b3eqv73f
> >
> > Basically, the argument is that
> > * the (dependabot) feature is too important to be disabled
> > * the annoyed people should filter out those mails (which I
> > did since no one at the time supported that they be diverted
> > to another ML).
> > Did anything change since then?
> > [Or do we eventually question the general anomaly that code
> > discussions have been almost completely off-loaded to GH?]
> >
> > Gilles
> >
> >>
>  Am 28.12.2021 um 19:20 schrieb Phil Steitz :
> >>>
> >>> I can no longer effectively monitor commits@ due to the spam
> generated by this tool.  I am afraid my eyeballs aren't the only ones going
> missing here and that is a problem much more severe than any value provided
> by this tool, IMO.
> >>>
> >>> Phil
> >>
> >> Bye, Thomas
> >
> > -
> > 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
>
>

Re: can we get rid of dependabot?

[Rob Tompkins]

Guys. I think dependabot is our greatest advantage in the work against security 
problems. I know she has her failings and is chatty. But, I think we should 
open a line of thinking about how best she can help. 

The reason she’s a pain in the ass is that we don’t have enough hands on the 
project making it better. I know I would help more, but I have to keep up with 
my father who’s a quadriplegic as well as a currently failing marriage. 

The answer is that we need more hands on the project. I wish I could be those 
hands but time and priorities keep me chained. 

Cheers,
-Rob

> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski  wrote:
> 
> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit :
>> 
>> +1
>> Thank you, Phil. This thing is a P.I.T.A.
> 
> In effect, from day one:
>   https://markmail.org/message/2vutc4p3b3eqv73f
> 
> Basically, the argument is that
> * the (dependabot) feature is too important to be disabled
> * the annoyed people should filter out those mails (which I
> did since no one at the time supported that they be diverted
> to another ML).
> Did anything change since then?
> [Or do we eventually question the general anomaly that code
> discussions have been almost completely off-loaded to GH?]
> 
> Gilles
> 
>> 
 Am 28.12.2021 um 19:20 schrieb Phil Steitz :
>>> 
>>> I can no longer effectively monitor commits@ due to the spam generated by 
>>> this tool.  I am afraid my eyeballs aren't the only ones going missing here 
>>> and that is a problem much more severe than any value provided by this 
>>> tool, IMO.
>>> 
>>> Phil
>> 
>> Bye, Thomas
> 
> -
> 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

Re: can we get rid of dependabot?

[Rob Tompkins]

> On Dec 28, 2021, at 1:57 PM, Gary Gregory  wrote:
> 
> Please no. Dependabot is a key tool for me. Inbox rules should be able to
> help you depending on your client.

Huge +1

I think we need to help GitHub figure out how to make it better. 

-Rob

> 
> Someone had suggested creating a new mailing lists for bots/tools a while
> back but it never happened.
> 
> Gary
> 
>> On Tue, Dec 28, 2021 at 1:20 PM Phil Steitz  wrote:
>> 
>> I can no longer effectively monitor commits@ due to the spam generated
>> by this tool.  I am afraid my eyeballs aren't the only ones going
>> missing here and that is a problem much more severe than any value
>> provided by this tool, IMO.
>> 
>> Phil
>> 
>> -
>> 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

Re: can we get rid of dependabot?

[Gilles Sadowski]

Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl  a écrit :
>
> +1
> Thank you, Phil. This thing is a P.I.T.A.

In effect, from day one:
   https://markmail.org/message/2vutc4p3b3eqv73f

Basically, the argument is that
* the (dependabot) feature is too important to be disabled
* the annoyed people should filter out those mails (which I
did since no one at the time supported that they be diverted
to another ML).
Did anything change since then?
[Or do we eventually question the general anomaly that code
discussions have been almost completely off-loaded to GH?]

Gilles

>
> > Am 28.12.2021 um 19:20 schrieb Phil Steitz :
> >
> > I can no longer effectively monitor commits@ due to the spam generated by 
> > this tool.  I am afraid my eyeballs aren't the only ones going missing here 
> > and that is a problem much more severe than any value provided by this 
> > tool, IMO.
> >
> > Phil
>
> Bye, Thomas

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

Re: can we get rid of dependabot?

[Thomas Vandahl]

+1
Thank you, Phil. This thing is a P.I.T.A.

> Am 28.12.2021 um 19:20 schrieb Phil Steitz :
> 
> I can no longer effectively monitor commits@ due to the spam generated by 
> this tool.  I am afraid my eyeballs aren't the only ones going missing here 
> and that is a problem much more severe than any value provided by this tool, 
> IMO.
> 
> Phil

Bye, Thomas 
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

Think for version plugin it is solved already so maybe just config to do so
we are all good :): https://www.mojohaus.org/versions-maven-plugin/rule.html

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 29 déc. 2021 à 02:27, Maxim Solodovnik  a
écrit :

> Versions maven plugin missing the option to skip alpha/beta/rc :)
>
>
> from mobile (sorry for typos ;)
>
>
> On Wed, Dec 29, 2021, 05:28 Romain Manni-Bucau 
> wrote:
>
> > Not sure, guess you have dependabot oovers and haters but let stay
> simple:
> >
> > 1. If maven version plugin does not do its job let's fix it,
> > 2. If release manager handles dep check before the release as most asf
> > project, let's drop dependabot,
> > 3. If not and dependabot is acgually useful let's make it more clever by
> > checking compat between dep, handle dep baseline (prevent to use servlet
> 4
> > if you must be compat with v2 for ex) and OSGi meta (how many commons
> > project validate it with dependabot?).
> >
> > From my experience 2 is the most efficient and cheaper but 3 is an option
> > if somebody wants to do the investment too.
> >
> > Le mar. 28 déc. 2021 à 23:03, Xeno Amess  a écrit :
> >
> > > I think most people like me actually do not hate dependabot but hate
> the
> > > email flood and notification flood it brings...
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:01:58 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > junit 5 rc for example
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:01:35 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > versions maven plugin's problem is it will bring you latest
> release，even
> > > rc release...
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:00:40 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > dependabot is useful but dependabot email is annoying.
> > > can we find a solution and kill the dependabot  emails？
> > >
> > > XenoAmess
> > > 
> > > From: Mark Thomas 
> > > Sent: Wednesday, December 29, 2021 5:52:54 AM
> > > To: dev@commons.apache.org 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > +1
> > >
> > > And it isn't just the notifications an upgrade is available. The
> > > associated GitHub emails are just as much of a problem.
> > >
> > > The Versions Maven Plugin would be a much better solution to this
> > problem.
> > > - Run it once as part of the pre-release process.
> > > - One commit to apply all pending updates.
> > > - Job done.
> > >
> > > Mark
> > >
> > >
> > > On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> > > > +1, a lot of false positives and useless noise so the gain is rather
> > not
> > > > positive for me too (and we revew deps before a release anyway...when
> > > there
> > > > are some important ones)
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a
> > > écrit :
> > > >
> > > >> I can no longer effectively monitor commits@ due to the spam
> > generated
> > > >> by this tool.  I am afraid my eyeballs aren't the only ones going
> > > >> missing here and that is a problem much more severe than any value
> > > >> provided by this tool, IMO.
> > > >>
> > > >> Phil
> > > >>
> > > >>
> -
> > > >> 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
> > >
> > >
> >
>

Re: can we get rid of dependabot?

[Maxim Solodovnik]

Versions maven plugin missing the option to skip alpha/beta/rc :)


from mobile (sorry for typos ;)


On Wed, Dec 29, 2021, 05:28 Romain Manni-Bucau 
wrote:

> Not sure, guess you have dependabot oovers and haters but let stay simple:
>
> 1. If maven version plugin does not do its job let's fix it,
> 2. If release manager handles dep check before the release as most asf
> project, let's drop dependabot,
> 3. If not and dependabot is acgually useful let's make it more clever by
> checking compat between dep, handle dep baseline (prevent to use servlet 4
> if you must be compat with v2 for ex) and OSGi meta (how many commons
> project validate it with dependabot?).
>
> From my experience 2 is the most efficient and cheaper but 3 is an option
> if somebody wants to do the investment too.
>
> Le mar. 28 déc. 2021 à 23:03, Xeno Amess  a écrit :
>
> > I think most people like me actually do not hate dependabot but hate the
> > email flood and notification flood it brings...
> >
> > XenoAmess
> > 
> > From: Xeno Amess 
> > Sent: Wednesday, December 29, 2021 6:01:58 AM
> > To: Commons Developers List 
> > Subject: Re: can we get rid of dependabot?
> >
> > junit 5 rc for example
> >
> > XenoAmess
> > ________________________
> > From: Xeno Amess 
> > Sent: Wednesday, December 29, 2021 6:01:35 AM
> > To: Commons Developers List 
> > Subject: Re: can we get rid of dependabot?
> >
> > versions maven plugin's problem is it will bring you latest release，even
> > rc release...
> >
> > XenoAmess
> > 
> > From: Xeno Amess 
> > Sent: Wednesday, December 29, 2021 6:00:40 AM
> > To: Commons Developers List 
> > Subject: Re: can we get rid of dependabot?
> >
> > dependabot is useful but dependabot email is annoying.
> > can we find a solution and kill the dependabot  emails？
> >
> > XenoAmess
> > 
> > From: Mark Thomas 
> > Sent: Wednesday, December 29, 2021 5:52:54 AM
> > To: dev@commons.apache.org 
> > Subject: Re: can we get rid of dependabot?
> >
> > +1
> >
> > And it isn't just the notifications an upgrade is available. The
> > associated GitHub emails are just as much of a problem.
> >
> > The Versions Maven Plugin would be a much better solution to this
> problem.
> > - Run it once as part of the pre-release process.
> > - One commit to apply all pending updates.
> > - Job done.
> >
> > Mark
> >
> >
> > On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> > > +1, a lot of false positives and useless noise so the gain is rather
> not
> > > positive for me too (and we revew deps before a release anyway...when
> > there
> > > are some important ones)
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a
> > écrit :
> > >
> > >> I can no longer effectively monitor commits@ due to the spam
> generated
> > >> by this tool.  I am afraid my eyeballs aren't the only ones going
> > >> missing here and that is a problem much more severe than any value
> > >> provided by this tool, IMO.
> > >>
> > >> Phil
> > >>
> > >> -
> > >> 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
> >
> >
>

Re: can we get rid of dependabot?

[Bernd Eckenfels]

Snyk can alert on CVEs and it also can sent summary reports, but not sure if it 
works good with organizational repositories and for open source organisations.

https://github.com/ecki/commons-vfs/pull/9

But +1 for getting rid of those notifications.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: sebb 
Gesendet: Wednesday, December 29, 2021 12:52:39 AM
An: Commons Developers List 
Betreff: Re: can we get rid of dependabot?

+1, I agree that dependabot (rhymes with spamalot) should disabled entirely.

Unfortunately moving the notification emails to a separate list won't
stop the noise, unless committers ignore the PRs it creates.
In which case, there's really no point in having it.

What we need is notifications ONLY when a dependency has a security issue.

Otherwise the sensible time to check and update dependencies is just
before a release.

Please let's stop the flood of largely useless mails - over 50% of
commits, issues and notification emails are now caused directly or
indirectly by dependabot.

If it were a human sending even a few of these messages we would have
banned them long ago.

Sebb.

On Tue, 28 Dec 2021 at 23:33, Gary Gregory  wrote:
>
> There is nothing to fix in Maven: Maven does not create a branch, run the
> GitHub Actions builds, and email you a report. Maven tells you what could
> be updated, that's it, and it works great. Apple and oranges.
>
> Gary
>
> On Tue, Dec 28, 2021 at 5:28 PM Romain Manni-Bucau 
> wrote:
>
> > Not sure, guess you have dependabot oovers and haters but let stay simple:
> >
> > 1. If maven version plugin does not do its job let's fix it,
> > 2. If release manager handles dep check before the release as most asf
> > project, let's drop dependabot,
> > 3. If not and dependabot is acgually useful let's make it more clever by
> > checking compat between dep, handle dep baseline (prevent to use servlet 4
> > if you must be compat with v2 for ex) and OSGi meta (how many commons
> > project validate it with dependabot?).
> >
> > From my experience 2 is the most efficient and cheaper but 3 is an option
> > if somebody wants to do the investment too.
> >
> > Le mar. 28 déc. 2021 à 23:03, Xeno Amess  a écrit :
> >
> > > I think most people like me actually do not hate dependabot but hate the
> > > email flood and notification flood it brings...
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:01:58 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > junit 5 rc for example
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:01:35 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > versions maven plugin's problem is it will bring you latest release，even
> > > rc release...
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:00:40 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > dependabot is useful but dependabot email is annoying.
> > > can we find a solution and kill the dependabot  emails？
> > >
> > > XenoAmess
> > > 
> > > From: Mark Thomas 
> > > Sent: Wednesday, December 29, 2021 5:52:54 AM
> > > To: dev@commons.apache.org 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > +1
> > >
> > > And it isn't just the notifications an upgrade is available. The
> > > associated GitHub emails are just as much of a problem.
> > >
> > > The Versions Maven Plugin would be a much better solution to this
> > problem.
> > > - Run it once as part of the pre-release process.
> > > - One commit to apply all pending updates.
> > > - Job done.
> > >
> > > Mark
> > >
> > >
> > > On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> > > > +1, a lot of false positives and useless noise so the gain is rather
> > not
> > > > positive for me too (and we revew deps before a release anyway...when
> > > there
> > > > are some important ones)
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https:/

Re: can we get rid of dependabot?

[sebb]

+1, I agree that dependabot (rhymes with spamalot) should disabled entirely.

Unfortunately moving the notification emails to a separate list won't
stop the noise, unless committers ignore the PRs it creates.
In which case, there's really no point in having it.

What we need is notifications ONLY when a dependency has a security issue.

Otherwise the sensible time to check and update dependencies is just
before a release.

Please let's stop the flood of largely useless mails - over 50% of
commits, issues and notification emails are now caused directly or
indirectly by dependabot.

If it were a human sending even a few of these messages we would have
banned them long ago.

Sebb.

On Tue, 28 Dec 2021 at 23:33, Gary Gregory  wrote:
>
> There is nothing to fix in Maven: Maven does not create a branch, run the
> GitHub Actions builds, and email you a report. Maven tells you what could
> be updated, that's it, and it works great. Apple and oranges.
>
> Gary
>
> On Tue, Dec 28, 2021 at 5:28 PM Romain Manni-Bucau 
> wrote:
>
> > Not sure, guess you have dependabot oovers and haters but let stay simple:
> >
> > 1. If maven version plugin does not do its job let's fix it,
> > 2. If release manager handles dep check before the release as most asf
> > project, let's drop dependabot,
> > 3. If not and dependabot is acgually useful let's make it more clever by
> > checking compat between dep, handle dep baseline (prevent to use servlet 4
> > if you must be compat with v2 for ex) and OSGi meta (how many commons
> > project validate it with dependabot?).
> >
> > From my experience 2 is the most efficient and cheaper but 3 is an option
> > if somebody wants to do the investment too.
> >
> > Le mar. 28 déc. 2021 à 23:03, Xeno Amess  a écrit :
> >
> > > I think most people like me actually do not hate dependabot but hate the
> > > email flood and notification flood it brings...
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:01:58 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > junit 5 rc for example
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:01:35 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > versions maven plugin's problem is it will bring you latest release，even
> > > rc release...
> > >
> > > XenoAmess
> > > 
> > > From: Xeno Amess 
> > > Sent: Wednesday, December 29, 2021 6:00:40 AM
> > > To: Commons Developers List 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > dependabot is useful but dependabot email is annoying.
> > > can we find a solution and kill the dependabot  emails？
> > >
> > > XenoAmess
> > > 
> > > From: Mark Thomas 
> > > Sent: Wednesday, December 29, 2021 5:52:54 AM
> > > To: dev@commons.apache.org 
> > > Subject: Re: can we get rid of dependabot?
> > >
> > > +1
> > >
> > > And it isn't just the notifications an upgrade is available. The
> > > associated GitHub emails are just as much of a problem.
> > >
> > > The Versions Maven Plugin would be a much better solution to this
> > problem.
> > > - Run it once as part of the pre-release process.
> > > - One commit to apply all pending updates.
> > > - Job done.
> > >
> > > Mark
> > >
> > >
> > > On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> > > > +1, a lot of false positives and useless noise so the gain is rather
> > not
> > > > positive for me too (and we revew deps before a release anyway...when
> > > there
> > > > are some important ones)
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >

Re: can we get rid of dependabot?

[Gary Gregory]

There is nothing to fix in Maven: Maven does not create a branch, run the
GitHub Actions builds, and email you a report. Maven tells you what could
be updated, that's it, and it works great. Apple and oranges.

Gary

On Tue, Dec 28, 2021 at 5:28 PM Romain Manni-Bucau 
wrote:

> Not sure, guess you have dependabot oovers and haters but let stay simple:
>
> 1. If maven version plugin does not do its job let's fix it,
> 2. If release manager handles dep check before the release as most asf
> project, let's drop dependabot,
> 3. If not and dependabot is acgually useful let's make it more clever by
> checking compat between dep, handle dep baseline (prevent to use servlet 4
> if you must be compat with v2 for ex) and OSGi meta (how many commons
> project validate it with dependabot?).
>
> From my experience 2 is the most efficient and cheaper but 3 is an option
> if somebody wants to do the investment too.
>
> Le mar. 28 déc. 2021 à 23:03, Xeno Amess  a écrit :
>
> > I think most people like me actually do not hate dependabot but hate the
> > email flood and notification flood it brings...
> >
> > XenoAmess
> > 
> > From: Xeno Amess 
> > Sent: Wednesday, December 29, 2021 6:01:58 AM
> > To: Commons Developers List 
> > Subject: Re: can we get rid of dependabot?
> >
> > junit 5 rc for example
> >
> > XenoAmess
> > ____________________
> > From: Xeno Amess 
> > Sent: Wednesday, December 29, 2021 6:01:35 AM
> > To: Commons Developers List 
> > Subject: Re: can we get rid of dependabot?
> >
> > versions maven plugin's problem is it will bring you latest release，even
> > rc release...
> >
> > XenoAmess
> > 
> > From: Xeno Amess 
> > Sent: Wednesday, December 29, 2021 6:00:40 AM
> > To: Commons Developers List 
> > Subject: Re: can we get rid of dependabot?
> >
> > dependabot is useful but dependabot email is annoying.
> > can we find a solution and kill the dependabot  emails？
> >
> > XenoAmess
> > 
> > From: Mark Thomas 
> > Sent: Wednesday, December 29, 2021 5:52:54 AM
> > To: dev@commons.apache.org 
> > Subject: Re: can we get rid of dependabot?
> >
> > +1
> >
> > And it isn't just the notifications an upgrade is available. The
> > associated GitHub emails are just as much of a problem.
> >
> > The Versions Maven Plugin would be a much better solution to this
> problem.
> > - Run it once as part of the pre-release process.
> > - One commit to apply all pending updates.
> > - Job done.
> >
> > Mark
> >
> >
> > On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> > > +1, a lot of false positives and useless noise so the gain is rather
> not
> > > positive for me too (and we revew deps before a release anyway...when
> > there
> > > are some important ones)
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a
> > écrit :
> > >
> > >> I can no longer effectively monitor commits@ due to the spam
> generated
> > >> by this tool.  I am afraid my eyeballs aren't the only ones going
> > >> missing here and that is a problem much more severe than any value
> > >> provided by this tool, IMO.
> > >>
> > >> Phil
> > >>
> > >> -
> > >> 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
> >
> >
>

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

Not sure, guess you have dependabot oovers and haters but let stay simple:

1. If maven version plugin does not do its job let's fix it,
2. If release manager handles dep check before the release as most asf
project, let's drop dependabot,
3. If not and dependabot is acgually useful let's make it more clever by
checking compat between dep, handle dep baseline (prevent to use servlet 4
if you must be compat with v2 for ex) and OSGi meta (how many commons
project validate it with dependabot?).

>From my experience 2 is the most efficient and cheaper but 3 is an option
if somebody wants to do the investment too.

Le mar. 28 déc. 2021 à 23:03, Xeno Amess  a écrit :

> I think most people like me actually do not hate dependabot but hate the
> email flood and notification flood it brings...
>
> XenoAmess
> 
> From: Xeno Amess 
> Sent: Wednesday, December 29, 2021 6:01:58 AM
> To: Commons Developers List 
> Subject: Re: can we get rid of dependabot?
>
> junit 5 rc for example
>
> XenoAmess
> 
> From: Xeno Amess 
> Sent: Wednesday, December 29, 2021 6:01:35 AM
> To: Commons Developers List 
> Subject: Re: can we get rid of dependabot?
>
> versions maven plugin's problem is it will bring you latest release，even
> rc release...
>
> XenoAmess
> 
> From: Xeno Amess 
> Sent: Wednesday, December 29, 2021 6:00:40 AM
> To: Commons Developers List 
> Subject: Re: can we get rid of dependabot?
>
> dependabot is useful but dependabot email is annoying.
> can we find a solution and kill the dependabot  emails？
>
> XenoAmess
> ____________
> From: Mark Thomas 
> Sent: Wednesday, December 29, 2021 5:52:54 AM
> To: dev@commons.apache.org 
> Subject: Re: can we get rid of dependabot?
>
> +1
>
> And it isn't just the notifications an upgrade is available. The
> associated GitHub emails are just as much of a problem.
>
> The Versions Maven Plugin would be a much better solution to this problem.
> - Run it once as part of the pre-release process.
> - One commit to apply all pending updates.
> - Job done.
>
> Mark
>
>
> On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> > +1, a lot of false positives and useless noise so the gain is rather not
> > positive for me too (and we revew deps before a release anyway...when
> there
> > are some important ones)
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a
> écrit :
> >
> >> I can no longer effectively monitor commits@ due to the spam generated
> >> by this tool.  I am afraid my eyeballs aren't the only ones going
> >> missing here and that is a problem much more severe than any value
> >> provided by this tool, IMO.
> >>
> >> Phil
> >>
> >> -
> >> 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
>
>

Re: can we get rid of dependabot?

[Xeno Amess]

I think most people like me actually do not hate dependabot but hate the email 
flood and notification flood it brings...

XenoAmess

From: Xeno Amess 
Sent: Wednesday, December 29, 2021 6:01:58 AM
To: Commons Developers List 
Subject: Re: can we get rid of dependabot?

junit 5 rc for example

XenoAmess

From: Xeno Amess 
Sent: Wednesday, December 29, 2021 6:01:35 AM
To: Commons Developers List 
Subject: Re: can we get rid of dependabot?

versions maven plugin's problem is it will bring you latest release，even rc 
release...

XenoAmess

From: Xeno Amess 
Sent: Wednesday, December 29, 2021 6:00:40 AM
To: Commons Developers List 
Subject: Re: can we get rid of dependabot?

dependabot is useful but dependabot email is annoying.
can we find a solution and kill the dependabot  emails？

XenoAmess

From: Mark Thomas 
Sent: Wednesday, December 29, 2021 5:52:54 AM
To: dev@commons.apache.org 
Subject: Re: can we get rid of dependabot?

+1

And it isn't just the notifications an upgrade is available. The
associated GitHub emails are just as much of a problem.

The Versions Maven Plugin would be a much better solution to this problem.
- Run it once as part of the pre-release process.
- One commit to apply all pending updates.
- Job done.

Mark


On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> +1, a lot of false positives and useless noise so the gain is rather not
> positive for me too (and we revew deps before a release anyway...when there
> are some important ones)
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :
>
>> I can no longer effectively monitor commits@ due to the spam generated
>> by this tool.  I am afraid my eyeballs aren't the only ones going
>> missing here and that is a problem much more severe than any value
>> provided by this tool, IMO.
>>
>> Phil
>>
>> -
>> 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

Re: can we get rid of dependabot?

[Xeno Amess]

junit 5 rc for example

XenoAmess

From: Xeno Amess 
Sent: Wednesday, December 29, 2021 6:01:35 AM
To: Commons Developers List 
Subject: Re: can we get rid of dependabot?

versions maven plugin's problem is it will bring you latest release，even rc 
release...

XenoAmess

From: Xeno Amess 
Sent: Wednesday, December 29, 2021 6:00:40 AM
To: Commons Developers List 
Subject: Re: can we get rid of dependabot?

dependabot is useful but dependabot email is annoying.
can we find a solution and kill the dependabot  emails？

XenoAmess

From: Mark Thomas 
Sent: Wednesday, December 29, 2021 5:52:54 AM
To: dev@commons.apache.org 
Subject: Re: can we get rid of dependabot?

+1

And it isn't just the notifications an upgrade is available. The
associated GitHub emails are just as much of a problem.

The Versions Maven Plugin would be a much better solution to this problem.
- Run it once as part of the pre-release process.
- One commit to apply all pending updates.
- Job done.

Mark


On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> +1, a lot of false positives and useless noise so the gain is rather not
> positive for me too (and we revew deps before a release anyway...when there
> are some important ones)
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :
>
>> I can no longer effectively monitor commits@ due to the spam generated
>> by this tool.  I am afraid my eyeballs aren't the only ones going
>> missing here and that is a problem much more severe than any value
>> provided by this tool, IMO.
>>
>> Phil
>>
>> -
>> 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

Re: can we get rid of dependabot?

[Xeno Amess]

versions maven plugin's problem is it will bring you latest release，even rc 
release...

XenoAmess

From: Xeno Amess 
Sent: Wednesday, December 29, 2021 6:00:40 AM
To: Commons Developers List 
Subject: Re: can we get rid of dependabot?

dependabot is useful but dependabot email is annoying.
can we find a solution and kill the dependabot  emails？

XenoAmess

From: Mark Thomas 
Sent: Wednesday, December 29, 2021 5:52:54 AM
To: dev@commons.apache.org 
Subject: Re: can we get rid of dependabot?

+1

And it isn't just the notifications an upgrade is available. The
associated GitHub emails are just as much of a problem.

The Versions Maven Plugin would be a much better solution to this problem.
- Run it once as part of the pre-release process.
- One commit to apply all pending updates.
- Job done.

Mark


On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> +1, a lot of false positives and useless noise so the gain is rather not
> positive for me too (and we revew deps before a release anyway...when there
> are some important ones)
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :
>
>> I can no longer effectively monitor commits@ due to the spam generated
>> by this tool.  I am afraid my eyeballs aren't the only ones going
>> missing here and that is a problem much more severe than any value
>> provided by this tool, IMO.
>>
>> Phil
>>
>> -
>> 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

Re: can we get rid of dependabot?

[Xeno Amess]

dependabot is useful but dependabot email is annoying.
can we find a solution and kill the dependabot  emails？

XenoAmess

From: Mark Thomas 
Sent: Wednesday, December 29, 2021 5:52:54 AM
To: dev@commons.apache.org 
Subject: Re: can we get rid of dependabot?

+1

And it isn't just the notifications an upgrade is available. The
associated GitHub emails are just as much of a problem.

The Versions Maven Plugin would be a much better solution to this problem.
- Run it once as part of the pre-release process.
- One commit to apply all pending updates.
- Job done.

Mark


On 28/12/2021 18:29, Romain Manni-Bucau wrote:
> +1, a lot of false positives and useless noise so the gain is rather not
> positive for me too (and we revew deps before a release anyway...when there
> are some important ones)
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :
>
>> I can no longer effectively monitor commits@ due to the spam generated
>> by this tool.  I am afraid my eyeballs aren't the only ones going
>> missing here and that is a problem much more severe than any value
>> provided by this tool, IMO.
>>
>> Phil
>>
>> -
>> 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

Re: can we get rid of dependabot?

[Mark Thomas]

+1

And it isn't just the notifications an upgrade is available. The 
associated GitHub emails are just as much of a problem.


The Versions Maven Plugin would be a much better solution to this problem.
- Run it once as part of the pre-release process.
- One commit to apply all pending updates.
- Job done.

Mark


On 28/12/2021 18:29, Romain Manni-Bucau wrote:

+1, a lot of false positives and useless noise so the gain is rather not
positive for me too (and we revew deps before a release anyway...when there
are some important ones)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :


I can no longer effectively monitor commits@ due to the spam generated
by this tool.  I am afraid my eyeballs aren't the only ones going
missing here and that is a problem much more severe than any value
provided by this tool, IMO.

Phil

-
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

Re: can we get rid of dependabot?

[Gilles Sadowski]

Le mar. 28 déc. 2021 à 19:57, Gary Gregory  a écrit :
>
> Please no. Dependabot is a key tool for me. Inbox rules should be able to
> help you depending on your client.
>
> Someone had suggested creating a new mailing lists for bots/tools a while
> back but it never happened.

It was more than a suggestion:
  https://markmail.org/message/7xsy4huc22qe2gly

Gilles

>
> Gary
>
> On Tue, Dec 28, 2021 at 1:20 PM Phil Steitz  wrote:
>
> > I can no longer effectively monitor commits@ due to the spam generated
> > by this tool.  I am afraid my eyeballs aren't the only ones going
> > missing here and that is a problem much more severe than any value
> > provided by this tool, IMO.
> >
> > Phil

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

Re: can we get rid of dependabot?

[Gary Gregory]

Please no. Dependabot is a key tool for me. Inbox rules should be able to
help you depending on your client.

Someone had suggested creating a new mailing lists for bots/tools a while
back but it never happened.

Gary

On Tue, Dec 28, 2021 at 1:20 PM Phil Steitz  wrote:

> I can no longer effectively monitor commits@ due to the spam generated
> by this tool.  I am afraid my eyeballs aren't the only ones going
> missing here and that is a problem much more severe than any value
> provided by this tool, IMO.
>
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: can we get rid of dependabot?

[Romain Manni-Bucau]

+1, a lot of false positives and useless noise so the gain is rather not
positive for me too (and we revew deps before a release anyway...when there
are some important ones)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 28 déc. 2021 à 19:20, Phil Steitz  a écrit :

> I can no longer effectively monitor commits@ due to the spam generated
> by this tool.  I am afraid my eyeballs aren't the only ones going
> missing here and that is a problem much more severe than any value
> provided by this tool, IMO.
>
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

can we get rid of dependabot?

[Phil Steitz]

I can no longer effectively monitor commits@ due to the spam generated 
by this tool.  I am afraid my eyeballs aren't the only ones going 
missing here and that is a problem much more severe than any value 
provided by this tool, IMO.


Phil

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