On Thu, 30 Dec 2021 at 21:39, Rob Tompkins <chtom...@gmail.com> wrote: > > 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.
The issue is *not* about robot or no robot. It is about this particular robot that causes so much noise. > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
