Why not just run dependabot weekly. We move slowly enough that weekly currently works. Until we can get more hands on the project, slower comms are indeed reasonable…right?
-Rob > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Saving dev/human resources is about having a CI, all mentionned plugins of > the thread support it properly while cronned. > Difference is the scope of the checks: CVE only, all deps, plugins and code > (which is where most people don't like since it is trivial to have false > positive and dependabot falls there). > > I agree CVE are a crucial topic but dependabot is NOT done for them, it is > done for dependencies as a whole and is full of bugs so until it is refined > to be more relevant and bulked differently (maybe *1* mail a week) then it > is not an option for an everyday work 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 à 15:18, Gary Gregory <garydgreg...@gmail.com> a >> écrit : >> >>> 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?* >> >> 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