You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Bresie <eb...@gmail.com> on 2022/01/02 15:36:18 UTC
Re: Re: can we get rid of dependabot?
Late to the discussion but I think what is being said and with a few follow up questions is…
The problem discussed is when a dependabot check occurs following a commit, it highlights out of date dependencies (possibly security related) which notifies folks via an automated email sent to multiple mailing list with the frequency of such resulting in giving mailing list overwhelmed by the frequent checks for dependencies updates. Is this correct?
It sounds like what is being proposed (and in work) is for the dependabot configuration to change the frequency, trigger, and/or destination for the emails…is this correct?
From dependency perspective, is the behavior, it notifies for the need for an update or does it create an automated updated via a generates “PR” to address direct and indirect dependency updates? Assume for PR case a “person in the loop” is still required to review and merge in the PR…right?
From a higher level, is it correct to say, this attempts to reduce the risk of security or out of date dependency issues by automating the version dependencies checks/updates in a given build and reduce the amount of time and manual involvement to reduce security (and other dependency) updates?
I hope this would be considered sooner in the pipeline and maybe for another thread, but…if someone has an upstream dependency of some type, and a “bad actors” corrupts and updates a given upstream dependency, would this potentially “automate the spread” of a “bad actors” dependency update? Assume the “person in the loop” would hopefully reduce the risk but just thinking worse case scenario here.
Eric Bresie
Ebresie@gmail.com (mailto:Ebresie@gmail.com)
> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker <boards@gmail.com (mailto:boards@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates <https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether it’s better to have robot eyes on the code and human eyes on the code. Stop arguing one side or the other. We need to find a way to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot correctly!
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > On Dec 29, 2021, at 1:57 PM, Phil Steitz <phil.steitz@gmail.com (mailto:phil.steitz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 12/29/21 8:43 AM, sebb wrote:
> > > > > > > > > > On Wed, 29 Dec 2021 at 14:53, Gary Gregory <garydgregory@gmail.com (mailto:garydgregory@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > > > On Wed, Dec 29, 2021 at 9:42 AM sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > >
> > > > > > > > > > > On Wed, 29 Dec 2021 at 14:18, Gary Gregory <garydgregory@gmail.com (mailto:garydgregory@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > > > > On Wed, Dec 29, 2021 at 9:07 AM sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory <garydgregory@gmail.com (mailto:garydgregory@gmail.com) <ma...@gmail.com>>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > One critical feature is that dependabot does all the builds for you
> > > > > > > > > > > on
> > > > > > > > > > > > > > GitHub Actions, this is an enormous time and resource saver!
> > > > > > > > > > > > > Not at all.
> > > > > > > > > > > > > Just the reverse.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It does NOT save resources, because it runs builds for updates that
> > > > > > > > > > > > > are not necessary at that point in time (or ever, in some cases).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Nor does it same time, because the the noise that it generates.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please stop pretending that Dependabot does things it does not (and
> > > > > > > > > > > > > likely cannot) do.
> > > > > > > > > > > > >
> > > > > > > > > > > > Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> > > > > > > > > > > > It's as simple as I stated:
> > > > > > > > > > > >
> > > > > > > > > > > > If Dependabot detects that a new version of a dependency is available,
> > > > > > > > > > > > creates a branch, runs a build, tells me the result and I have a PR I can
> > > > > > > > > > > > merge, *that is all work and time *I* do not have to do manually! Why is
> > > > > > > > > > > > that so hard to understand?*
> > > > > > > > > > > Of course I understand that.
> > > > > > > > > > >
> > > > > > > > > > Phew! :-)
> > > > > > > > > >
> > > > > > > > > > > However, just because a new version is available does NOT mean that it
> > > > > > > > > > > has to be updated there and then.
> > > > > > > > > > > Sometimes it never needs to be updated.
> > > > > > > > > > >
> > > > > > > > > > You can't know if you need to make a decision unless someone asks you to
> > > > > > > > > > make it. I don't know out of thin air that a new version is available.
> > > > > > > > > You can be pro-active and do a dependency check yourself.
> > > > > > > > > And you can look out for security bulletins.
> > > > > > > > >
> > > > > > > > > That's what we used to do.
> > > > > > > > >
> > > > > > > > > > > Changes to dependencies occur much more frequently than component releases.
> > > > > > > > > > > So often there will be several mails for the same dependency.
> > > > > > > > > > >
> > > > > > > > > > > In the past, the approach was to check for new (and useful) updates
> > > > > > > > > > > shortly before a release.
> > > > > > > > > > >
> > > > > > > > > > That must have been before my time and it seems like a horrible idea: The
> > > > > > > > > > software is stable after a few months of activity and it's time to make a
> > > > > > > > > > release, so the day before a release, you change all the dependencies, and
> > > > > > > > > > cross your fingers? Yikes!
> > > > > > > > > That is NOT what I said.
> > > > > > > > >
> > > > > > > > > Obviously one would start working on version updates some time before
> > > > > > > > > the release.
> > > > > > > > > Days or weeks rather than months or years.
> > > > > > > > >
> > > > > > > > > > > Generally all the versions would be updated at the same time, instead
> > > > > > > > > > > of individually.
> > > > > > > > > > >
> > > > > > > > > > Not here, if update 10 dependencies and a build fails, then what? I go back
> > > > > > > > > > to square one and update each, one at a time, until I find the culprit,
> > > > > > > > > > which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> > > > > > > > > > for components like VFS, Configuration, and others.
> > > > > > > > > Well yes, but how likely is there to be a failure in such circumstances?
> > > > > > > > >
> > > > > > > > > If the build does not fail, you have saved the noise from at least 9
> > > > > > > > > updates which are generally 3 emails per update.
> > > > > > > > >
> > > > > > > > > If it does fail, you will have wasted 2 cycles: the original commit of
> > > > > > > > > 10, and the revert. And only 2 emails.
> > > > > > > >
> > > > > > > > +1 and you will get many thanks from those trying to follow commits and better review of the actual commits. It seems badly broken to me that in order to effectively review commits to the commons components that I watch I have to write filters to ignore most of them. The damage from making it harder to review commits is far greater than the benefit this thing provides. Actual code commits are where bugs and vulnerabilities get introduced. Just like mixing formatting changes with functional code changes is a bad practice, spamming commits@ with a bunch of auto-branch creations is bad as it dilutes eyeballs, which are the most important community resource that we have in ensuring code quality and security.
> > > > > > > >
> > > > > > > > Phil
> > > > > > > > >
> > > > > > > > > > Gary
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > Gary
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > Gary
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Dec 29, 2021, 08:51 Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > > > > > > > > > > > > rmannibucau@gmail.com (mailto:rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > > > > > > > > > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > > > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Le mer. 29 déc. 2021 à 14:39, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)>
> > > > > > > > > > > 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 <
> > > > > > > > > > > gilleseran@gmail.com (mailto:gilleseran@gmail.com)
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl <tv@apache.org (mailto:tv@apache.org)>
> > > > > > > > > > > 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.steitz@gmail.com (mailto:phil.steitz@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-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org) <ma...@commons.apache.org>
> > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org) <ma...@commons.apache.org>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
>
Re: Re: can we get rid of dependabot?
Posted by Eric Bresie <eb...@gmail.com>.
Noticed on recent dependabot PR the below being added to the PR.
Would using any of these options (i.e. like @dependabot close which prevent
some of the repeats notifications) help?
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- @dependabot rebase will rebase this PR
- @dependabot recreate will recreate this PR, overwriting any edits that
have been made to it
- @dependabot merge will merge this PR after your CI passes on it
- @dependabot squash and merge will squash and merge this PR after your
CI passes on it
- @dependabot cancel merge will cancel a previously requested merge and
block automerging
- @dependabot reopen will reopen this PR if it is closed
- *@dependabot close will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually*
- @dependabot ignore this major version will close this PR and stop
Dependabot creating any more for this major version (unless you reopen the
PR or upgrade to it yourself)
- @dependabot ignore this minor version will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen the
PR or upgrade to it yourself)
- @dependabot ignore this dependency will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the PR
or upgrade to it yourself)
On Sun, Jan 2, 2022 at 9:36 AM Eric Bresie <eb...@gmail.com> wrote:
> Late to the discussion but I think what is being said and with a few
> follow up questions is…
>
> The problem discussed is when a dependabot check occurs following a
> commit, it highlights out of date dependencies (possibly security related)
> which notifies folks via an automated email sent to multiple mailing list
> with the frequency of such resulting in giving mailing list overwhelmed by
> the frequent checks for dependencies updates. Is this correct?
>
> It sounds like what is being proposed (and in work) is for the dependabot
> configuration to change the frequency, trigger, and/or destination for the
> emails…is this correct?
>
> From dependency perspective, is the behavior, it notifies for the need for
> an update or does it create an automated updated via a generates “PR” to
> address direct and indirect dependency updates? Assume for PR case a
> “person in the loop” is still required to review and merge in the PR…right?
>
> From a higher level, is it correct to say, this attempts to reduce the
> risk of security or out of date dependency issues by automating the version
> dependencies checks/updates in a given build and reduce the amount of time
> and manual involvement to reduce security (and other dependency) updates?
>
> I hope this would be considered sooner in the pipeline and maybe for
> another thread, but…if someone has an upstream dependency of some type, and
> a “bad actors” corrupts and updates a given upstream dependency, would this
> potentially “automate the spread” of a “bad actors” dependency update?
> Assume the “person in the loop” would hopefully reduce the risk but just
> thinking worse case scenario here.
>
>
> Eric Bresie
> Ebresie@gmail.com
>
> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins <ch...@gmail.com>
> wrote:
> I believe that we already have begun to do this. -Rob
>
> On Dec 30, 2021, at 6:16 PM, sebb <se...@gmail.com> wrote:
>
> Those of you who want to keep the robot, please use the instructions
> to reduce the spam.
>
> On Thu, 30 Dec 2021 at 22:51, Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
> On Dec 30, 2021, at 5:50 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>
> There are tons of options to configure. The defaults are handy for
> smaller projects, but they are clearly spammy for larger ones like this.
>
>
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> <
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
>
>
>
> +1
>
> --
> Matt Sicker
>
> On Dec 30, 2021, at 16:48, Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
> On Dec 30, 2021, at 5:37 PM, sebb <sebbaz@gmail.com <
> mailto:sebbaz@gmail.com <se...@gmail.com>>> wrote:
>
>
> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins <chtompki@gmail.com <
> mailto:chtompki@gmail.com <ch...@gmail.com>>> wrote:
>
>
> Guys. The fundamental argument underpinng all this is whether it’s better
> to have robot eyes on the code and human eyes on the code. Stop arguing one
> side or the other. We need to find a way to do both successfully.
>
>
> The issue is *not* about robot or no robot.
>
> It is about this particular robot that causes so much noise.
>
>
> Yes! That’s right so we need to figure out how to use the robot correctly!
>
>
>
>
> On Dec 29, 2021, at 1:57 PM, Phil Steitz <phil.steitz@gmail.com <
> mailto:phil.steitz@gmail.com <ph...@gmail.com>>> wrote:
>
>
>
>
> On 12/29/21 8:43 AM, sebb wrote:
>
> On Wed, 29 Dec 2021 at 14:53, Gary Gregory <garydgregory@gmail.com <
> mailto:garydgregory@gmail.com <ga...@gmail.com>>> wrote:
>
> On Wed, Dec 29, 2021 at 9:42 AM sebb <sebbaz@gmail.com <
> mailto:sebbaz@gmail.com <se...@gmail.com>>> wrote:
>
>
> On Wed, 29 Dec 2021 at 14:18, Gary Gregory <garydgregory@gmail.com <
> mailto:garydgregory@gmail.com <ga...@gmail.com>>> wrote:
>
> On Wed, Dec 29, 2021 at 9:07 AM sebb <sebbaz@gmail.com <
> mailto:sebbaz@gmail.com <se...@gmail.com>>> wrote:
>
> On Wed, 29 Dec 2021 at 13:54, Gary Gregory <garydgregory@gmail.com <
> mailto:garydgregory@gmail.com <ga...@gmail.com>>>
>
> wrote:
>
> One critical feature is that dependabot does all the builds for you
>
> on
>
> GitHub Actions, this is an enormous time and resource saver!
>
> Not at all.
> Just the reverse.
>
> It does NOT save resources, because it runs builds for updates that
> are not necessary at that point in time (or ever, in some cases).
>
> Nor does it same time, because the the noise that it generates.
>
>
> Please stop pretending that Dependabot does things it does not (and
> likely cannot) do.
>
> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> It's as simple as I stated:
>
> If Dependabot detects that a new version of a dependency is available,
> creates a branch, runs a build, tells me the result and I have a PR I can
> merge, *that is all work and time *I* do not have to do manually! Why is
> that so hard to understand?*
>
> Of course I understand that.
>
> Phew! :-)
>
> However, just because a new version is available does NOT mean that it
> has to be updated there and then.
> Sometimes it never needs to be updated.
>
> You can't know if you need to make a decision unless someone asks you to
> make it. I don't know out of thin air that a new version is available.
>
> You can be pro-active and do a dependency check yourself.
> And you can look out for security bulletins.
>
> That's what we used to do.
>
> Changes to dependencies occur much more frequently than component
> releases.
> So often there will be several mails for the same dependency.
>
> In the past, the approach was to check for new (and useful) updates
> shortly before a release.
>
> That must have been before my time and it seems like a horrible idea: The
> software is stable after a few months of activity and it's time to make a
> release, so the day before a release, you change all the dependencies, and
> cross your fingers? Yikes!
>
> That is NOT what I said.
>
> Obviously one would start working on version updates some time before
> the release.
> Days or weeks rather than months or years.
>
> Generally all the versions would be updated at the same time, instead
> of individually.
>
> Not here, if update 10 dependencies and a build fails, then what? I go
> back
> to square one and update each, one at a time, until I find the culprit,
> which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> for components like VFS, Configuration, and others.
>
> Well yes, but how likely is there to be a failure in such circumstances?
>
> If the build does not fail, you have saved the noise from at least 9
> updates which are generally 3 emails per update.
>
> If it does fail, you will have wasted 2 cycles: the original commit of
> 10, and the revert. And only 2 emails.
>
>
> +1 and you will get many thanks from those trying to follow commits and
> better review of the actual commits. It seems badly broken to me that in
> order to effectively review commits to the commons components that I watch
> I have to write filters to ignore most of them. The damage from making it
> harder to review commits is far greater than the benefit this thing
> provides. Actual code commits are where bugs and vulnerabilities get
> introduced. Just like mixing formatting changes with functional code
> changes is a bad practice, spamming commits@ with a bunch of auto-branch
> creations is bad as it dilutes eyeballs, which are the most important
> community resource that we have in ensuring code quality and security.
>
> Phil
>
>
> Gary
>
>
> Gary
>
>
> Gary
>
> On Wed, Dec 29, 2021, 08:51 Rob Tompkins <ch...@gmail.com> wrote:
>
>
> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
>
> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
>
> https://github.com/rmannibucau> |
>
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
>
>
>
> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins <ch...@gmail.com>
>
> 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 <
>
> gilleseran@gmail.com
>
> wrote:
>
> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl <tv...@apache.org>
>
> 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.steitz@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <
> mailto:dev-unsubscribe@commons.apache.org
> <de...@commons.apache.org>>
> For additional commands, e-mail: dev-help@commons.apache.org <
> mailto:dev-help@commons.apache.org <de...@commons.apache.org>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Eric Bresie
ebresie@gmail.com
Re: Re: can we get rid of dependabot?
Posted by Xeno Amess <xe...@gmail.com>.
IMO it is the dependency's developer's duti to keep their private key safe, and oss 's duty to keep the uploaded dependency stored and delivered safe.
If you really think to apply zero trust in this way, maybe we shall also think git, github, maven, jdk, system,all of them have possibility to corrupt the artiface.
XenoAmess
________________________________
From: Eric Bresie <eb...@gmail.com>
Sent: Sunday, January 2, 2022 11:36:18 PM
To: dev@commons.apache.org <de...@commons.apache.org>
Subject: Re: Re: can we get rid of dependabot?
Late to the discussion but I think what is being said and with a few follow up questions is…
The problem discussed is when a dependabot check occurs following a commit, it highlights out of date dependencies (possibly security related) which notifies folks via an automated email sent to multiple mailing list with the frequency of such resulting in giving mailing list overwhelmed by the frequent checks for dependencies updates. Is this correct?
It sounds like what is being proposed (and in work) is for the dependabot configuration to change the frequency, trigger, and/or destination for the emails…is this correct?
From dependency perspective, is the behavior, it notifies for the need for an update or does it create an automated updated via a generates “PR” to address direct and indirect dependency updates? Assume for PR case a “person in the loop” is still required to review and merge in the PR…right?
From a higher level, is it correct to say, this attempts to reduce the risk of security or out of date dependency issues by automating the version dependencies checks/updates in a given build and reduce the amount of time and manual involvement to reduce security (and other dependency) updates?
I hope this would be considered sooner in the pipeline and maybe for another thread, but…if someone has an upstream dependency of some type, and a “bad actors” corrupts and updates a given upstream dependency, would this potentially “automate the spread” of a “bad actors” dependency update? Assume the “person in the loop” would hopefully reduce the risk but just thinking worse case scenario here.
Eric Bresie
Ebresie@gmail.com (mailto:Ebresie@gmail.com)
> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker <boards@gmail.com (mailto:boards@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates <https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether it’s better to have robot eyes on the code and human eyes on the code. Stop arguing one side or the other. We need to find a way to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot correctly!
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > On Dec 29, 2021, at 1:57 PM, Phil Steitz <phil.steitz@gmail.com (mailto:phil.steitz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 12/29/21 8:43 AM, sebb wrote:
> > > > > > > > > > On Wed, 29 Dec 2021 at 14:53, Gary Gregory <garydgregory@gmail.com (mailto:garydgregory@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > > > On Wed, Dec 29, 2021 at 9:42 AM sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > >
> > > > > > > > > > > On Wed, 29 Dec 2021 at 14:18, Gary Gregory <garydgregory@gmail.com (mailto:garydgregory@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > > > > On Wed, Dec 29, 2021 at 9:07 AM sebb <sebbaz@gmail.com (mailto:sebbaz@gmail.com) <ma...@gmail.com>> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory <garydgregory@gmail.com (mailto:garydgregory@gmail.com) <ma...@gmail.com>>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > One critical feature is that dependabot does all the builds for you
> > > > > > > > > > > on
> > > > > > > > > > > > > > GitHub Actions, this is an enormous time and resource saver!
> > > > > > > > > > > > > Not at all.
> > > > > > > > > > > > > Just the reverse.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It does NOT save resources, because it runs builds for updates that
> > > > > > > > > > > > > are not necessary at that point in time (or ever, in some cases).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Nor does it same time, because the the noise that it generates.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please stop pretending that Dependabot does things it does not (and
> > > > > > > > > > > > > likely cannot) do.
> > > > > > > > > > > > >
> > > > > > > > > > > > Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
> > > > > > > > > > > > It's as simple as I stated:
> > > > > > > > > > > >
> > > > > > > > > > > > If Dependabot detects that a new version of a dependency is available,
> > > > > > > > > > > > creates a branch, runs a build, tells me the result and I have a PR I can
> > > > > > > > > > > > merge, *that is all work and time *I* do not have to do manually! Why is
> > > > > > > > > > > > that so hard to understand?*
> > > > > > > > > > > Of course I understand that.
> > > > > > > > > > >
> > > > > > > > > > Phew! :-)
> > > > > > > > > >
> > > > > > > > > > > However, just because a new version is available does NOT mean that it
> > > > > > > > > > > has to be updated there and then.
> > > > > > > > > > > Sometimes it never needs to be updated.
> > > > > > > > > > >
> > > > > > > > > > You can't know if you need to make a decision unless someone asks you to
> > > > > > > > > > make it. I don't know out of thin air that a new version is available.
> > > > > > > > > You can be pro-active and do a dependency check yourself.
> > > > > > > > > And you can look out for security bulletins.
> > > > > > > > >
> > > > > > > > > That's what we used to do.
> > > > > > > > >
> > > > > > > > > > > Changes to dependencies occur much more frequently than component releases.
> > > > > > > > > > > So often there will be several mails for the same dependency.
> > > > > > > > > > >
> > > > > > > > > > > In the past, the approach was to check for new (and useful) updates
> > > > > > > > > > > shortly before a release.
> > > > > > > > > > >
> > > > > > > > > > That must have been before my time and it seems like a horrible idea: The
> > > > > > > > > > software is stable after a few months of activity and it's time to make a
> > > > > > > > > > release, so the day before a release, you change all the dependencies, and
> > > > > > > > > > cross your fingers? Yikes!
> > > > > > > > > That is NOT what I said.
> > > > > > > > >
> > > > > > > > > Obviously one would start working on version updates some time before
> > > > > > > > > the release.
> > > > > > > > > Days or weeks rather than months or years.
> > > > > > > > >
> > > > > > > > > > > Generally all the versions would be updated at the same time, instead
> > > > > > > > > > > of individually.
> > > > > > > > > > >
> > > > > > > > > > Not here, if update 10 dependencies and a build fails, then what? I go back
> > > > > > > > > > to square one and update each, one at a time, until I find the culprit,
> > > > > > > > > > which to me is a waste of time. BTW, 10 dependencies is not unreasonable
> > > > > > > > > > for components like VFS, Configuration, and others.
> > > > > > > > > Well yes, but how likely is there to be a failure in such circumstances?
> > > > > > > > >
> > > > > > > > > If the build does not fail, you have saved the noise from at least 9
> > > > > > > > > updates which are generally 3 emails per update.
> > > > > > > > >
> > > > > > > > > If it does fail, you will have wasted 2 cycles: the original commit of
> > > > > > > > > 10, and the revert. And only 2 emails.
> > > > > > > >
> > > > > > > > +1 and you will get many thanks from those trying to follow commits and better review of the actual commits. It seems badly broken to me that in order to effectively review commits to the commons components that I watch I have to write filters to ignore most of them. The damage from making it harder to review commits is far greater than the benefit this thing provides. Actual code commits are where bugs and vulnerabilities get introduced. Just like mixing formatting changes with functional code changes is a bad practice, spamming commits@ with a bunch of auto-branch creations is bad as it dilutes eyeballs, which are the most important community resource that we have in ensuring code quality and security.
> > > > > > > >
> > > > > > > > Phil
> > > > > > > > >
> > > > > > > > > > Gary
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > Gary
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > Gary
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Dec 29, 2021, 08:51 Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
> > > > > > > > > > > > > rmannibucau@gmail.com (mailto:rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > > > > > > > > > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > > > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Le mer. 29 déc. 2021 à 14:39, Rob Tompkins <chtompki@gmail.com (mailto:chtompki@gmail.com)>
> > > > > > > > > > > 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 <
> > > > > > > > > > > gilleseran@gmail.com (mailto:gilleseran@gmail.com)
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl <tv@apache.org (mailto:tv@apache.org)>
> > > > > > > > > > > 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.steitz@gmail.com (mailto:phil.steitz@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-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org) <ma...@commons.apache.org>
> > > > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org) <ma...@commons.apache.org>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> > For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org (mailto:dev-unsubscribe@commons.apache.org)
> For additional commands, e-mail: dev-help@commons.apache.org (mailto:dev-help@commons.apache.org)
>