All these version pins, notification settings, etc., are all configurable in the Dependabot config file. -- Matt Sicker
> On Dec 29, 2021, at 09:22, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > @Rob: not sure dependabot would get commits permissions anytime soon, it is > really an automotion thing on one side - we already had since years before > dependabot was a thing BTW - and it would be a poor committer on another > side, since it does changes without validating them or reviewing its impact > in the downstream projects - once again you get a lot of broken PR with > dependabot, I can see commons is not that affected because the dependencies > of commons are light in general but look any other project, it is pure > noise and a good way to break the project (incompatibility with a > dependency, broken OSGi metada, upgrade making a change at compile time - > bytecode breaking change which is invisible with any test suite until you > use compare with previous version - clirr or alike + test, plus it would > enable to use an up to date API when you need to support more so you can > break your consumers - upgrade junit5 to 5.8 and start using 5.8 API when > you must support users relying on junit 5.6 for ex). So the question is > 100% the ROI. Dependabot doing a lot of noise and enforcing a lot of work - > if not ignored - it costs a lot whereas dependency upgrades and CVE > management is very very cheap in a project life, even for big ones like > Apache TomEE, so don't think it can be justified as of today. > > 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 à 16:10, Rob Tompkins <chtom...@gmail.com> a écrit : > >> Guys….let us blind our eyes to the source. We are taking about kicking our >> most excited contributor. Are we not? If dependabot were a person they >> would likely have gotten commit rights and be in the PMC. Granted, they’d >> have taken some advice and slowed down a bit and maybe with some steering >> we can accomplish just that. >> >> My last penny, >> -Rob >> >>> On Dec 29, 2021, at 9:53 AM, 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. >>> >>> >>>> >>>> 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! >>> >>> >>>> 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. >>> >>> 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
