This feels like a "Don't shoot the messenger" issue: Some people really don't like this mail carrier and uniform ;-)
Gary On Thu, Dec 30, 2021 at 5:37 PM sebb <seb...@gmail.com> wrote: > 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 > >
