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: [VOTE] Release Apache Commons JCS 3.1 based on RC1

[Bruno P. Kinoshita]

Just remembered seeing some classes in JCS that had Blocking in the name. Maybe 
it is intentional to use that SecureRandom implementation.

In which case I think the best option would be to re-write the test that fails 
on environments where /dev/random is slow.

Cheers
Bruno

Sent from Yahoo Mail on Android 
 
  On Fri, 31 Dec 2021 at 10:05, Bruno P. 
Kinoshita wrote:   Hi,

Thomas has had a lot of patience troubleshooting this issue with me off-list 
(thanks heaps!). Not only remotely, but I think we are on opposite timezones 
too.

Yesterday Thomas suggested to look at EncryptingSerializer, and also to look at 
the time that my machine was taking to get data from /dev/random. Turns out 
that was a good suggestion, as /dev/random is very slow on my old Thinkpad 
(maybe some daemon that I disabled, or another BIOS/OS setting?.

It never caused any issue on my environment - that I could notice, at least. 
But for Commons JCS the unit tests take a very long time to run. The call to 
this.secureRandom.nextBytes() in EncryptingSerializer takes about 1 minute.

I configured my JVM with the java.security configuration file to use 
/dev/urandom, but the tests still failed. Tried /dev/./urandom (found it in 
some Tomcat docs) but it made not difference.

Looking at EncrytpingSerializer, it calls SecureRandom.getInstanceStrong(). 
With a debugger, I confirmed that it returned a NativePRNGBlocking, which 
states in its docs that it uses /dev/random. Changing that to 
`this.secureRandom = new SecureRandom()` the tests for me pass with `mvn clean 
test install site` in 5-6 minutes, with no issues.


I had a quick look at commons-rng, and saw that it uses `SecureRandom 
secureRandom = new SecureRandom()`. Looking at that constructor docs, it 
appears that it chooses the best random generator based on the list of 
available providers. So maybe replacing `SecureRandom.getInstanceStrong` by 
`new SecureRandom()`, and documenting to users that they must specify the best 
option for their environment, preferably one that generates random-enough data, 
could be an improvement for a next release? (didn't have time to dig more and 
see the implications of doing so, maybe others here have more experience, other 
ideas?)


I didn't have time to look if that `.getInstanceStrong` was introduced in this 
release, but if not, and since no users are reporting any issues with that, I 
guess it is not a blocker? Assuming that's correct, I'll leave my +1 here.

And thank you again, Thomas!

Cheers
Bruno




    On Thursday, 30 December 2021, 04:12:03 am NZDT, Thomas Vandahl 
 wrote:  
 
 > Am 29.12.2021 um 16:06 schrieb Gary Gregory :
> 
> Is this test failure being addressed?

Well, "addressed" is a big word for what I'm currently trying. "looked at" is 
closer to what happens.

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

    

Re: [VOTE] Release Apache Commons JCS 3.1 based on RC1

[Bruno P. Kinoshita]

 Hi,

Thomas has had a lot of patience troubleshooting this issue with me off-list 
(thanks heaps!). Not only remotely, but I think we are on opposite timezones 
too.

Yesterday Thomas suggested to look at EncryptingSerializer, and also to look at 
the time that my machine was taking to get data from /dev/random. Turns out 
that was a good suggestion, as /dev/random is very slow on my old Thinkpad 
(maybe some daemon that I disabled, or another BIOS/OS setting?.

It never caused any issue on my environment - that I could notice, at least. 
But for Commons JCS the unit tests take a very long time to run. The call to 
this.secureRandom.nextBytes() in EncryptingSerializer takes about 1 minute.

I configured my JVM with the java.security configuration file to use 
/dev/urandom, but the tests still failed. Tried /dev/./urandom (found it in 
some Tomcat docs) but it made not difference.

Looking at EncrytpingSerializer, it calls SecureRandom.getInstanceStrong(). 
With a debugger, I confirmed that it returned a NativePRNGBlocking, which 
states in its docs that it uses /dev/random. Changing that to 
`this.secureRandom = new SecureRandom()` the tests for me pass with `mvn clean 
test install site` in 5-6 minutes, with no issues.


I had a quick look at commons-rng, and saw that it uses `SecureRandom 
secureRandom = new SecureRandom()`. Looking at that constructor docs, it 
appears that it chooses the best random generator based on the list of 
available providers. So maybe replacing `SecureRandom.getInstanceStrong` by 
`new SecureRandom()`, and documenting to users that they must specify the best 
option for their environment, preferably one that generates random-enough data, 
could be an improvement for a next release? (didn't have time to dig more and 
see the implications of doing so, maybe others here have more experience, other 
ideas?)


I didn't have time to look if that `.getInstanceStrong` was introduced in this 
release, but if not, and since no users are reporting any issues with that, I 
guess it is not a blocker? Assuming that's correct, I'll leave my +1 here.

And thank you again, Thomas!

Cheers
Bruno




On Thursday, 30 December 2021, 04:12:03 am NZDT, Thomas Vandahl 
 wrote:  
 
 > Am 29.12.2021 um 16:06 schrieb Gary Gregory :
> 
> Is this test failure being addressed?

Well, "addressed" is a big word for what I'm currently trying. "looked at" is 
closer to what happens.

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?

[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