I still yet don’t see how thoughtful automation using dependabot doesn’t win out.
So the idea behind using a double negative in a sentence like above, is to imply that there is more than just a “yes/no” answer to the question. There is the beginnings (a few choices) of a veritable continuum of possibilities using computers to help us here with our security. The question isn’t if we implement!!!!!!! It’s how* we implement. -Rob > On Dec 29, 2021, at 10:44 AM, sebb <seb...@gmail.com> 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. > >> 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
