@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 > >
