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.
> On Dec 29, 2021, at 1:57 PM, Phil Steitz <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> 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. > > +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
