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 

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: Has Dependabot alerted us to any security issues?

[sebb]

On Wed, 29 Dec 2021 at 14:49, Xeno Amess  wrote:
>
> log4j2 recently, in vfs...

Log4j2 would have been known about without Dependabot.

> sebb  于2021年12月29日周三 22:48写道：
>
> > Genuine question: has Dependabot alerted us to any security issues?
> >
> > If so which ones, and was it the only alert mechanism for that issue?
> >
> > Sebb
> >
> > -
> > 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]

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 

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 

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
> > >>> 

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 

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

[Thomas Vandahl]

> 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?

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

[Gary Gregory]

FWIW, from the git tag, I run 'mvn clean install' and it passes but I think
we should make it easier to make reviewers pass builds since we do not
always have a lot of reviewers ;-)

Is this test failure being addressed?

TY!
Gary

PS: My set up is:

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.1", arch: "x86_64", family: "mac"

Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST
2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64

GG

On Tue, Dec 28, 2021 at 11:44 AM Thomas Vandahl  wrote:

> > Am 28.12.2021 um 13:01 schrieb Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br.INVALID>:
> >
> > `mvn clean test install site` took a few minutes, but it just finished
> running. Below the error that just happened again on my environment
> (appears to be consistent for me):
> >
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR]   SerializerUnitTest.testReadWrite:116 [key:0] should not be
> null, Region Name = blockRegion2
>
> Can you send me the log file please (direct mail, supposed to be in
> target/) If the test fails consistently, please run just that test because
> the log file is being overwritten every time.
>
> > [INFO] Apache Commons JCS :: Core . FAILURE
> [17:44 min]
>
> =:-o That's actually a *lot* of time. My seven year old Macbook needs
> about four minutes for the same task. Maybe there's a timing issue.
>
> 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?

[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: Has Dependabot alerted us to any security issues?

[John Patrick]

snyk just looks at security issues, not all avaliable updates.

i see dependabot (personally use renovate bot as dependabot has a broken
security mode regarding forks, as you can't disable dependabot on a fork),
as pro-actively upgrading dependencies, so the older dependency with a
security issue is then not being used when the venerability gets announced
as you have already upgraded.

John


On Wed, 29 Dec 2021 at 14:48, sebb  wrote:

> Genuine question: has Dependabot alerted us to any security issues?
>
> If so which ones, and was it the only alert mechanism for that issue?
>
> Sebb
>
> -
> 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]

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: Has Dependabot alerted us to any security issues?

[Xeno Amess]

log4j2 recently, in vfs...

sebb  于2021年12月29日周三 22:48写道：

> Genuine question: has Dependabot alerted us to any security issues?
>
> If so which ones, and was it the only alert mechanism for that issue?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Has Dependabot alerted us to any security issues?

[sebb]

Genuine question: has Dependabot alerted us to any security issues?

If so which ones, and was it the only alert mechanism for that issue?

Sebb

-
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?

[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 

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:
 

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 

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?

[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