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