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
