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