I believe that we already have begun to do this. -Rob > On Dec 30, 2021, at 6:16 PM, sebb <seb...@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 <chtom...@gmail.com> wrote: >> >> >> >>>> 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 >> > > --------------------------------------------------------------------- > 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
