BTW: we always think about "commons" but there is not really a "commons" but there are commons so why not letting each project "lead" - the people actually working on the project which means it can change later - handling it. While it is a toggle to enable in asf.yaml or as easy as that I think it can be a solution. Then only point to discuss is: dependabot-notificatons@ per project or not - here again it makes sense per project IMHO since we are far behind a consistent thing where anyone contributing to one project cn contribute to all projects these day, no? Can't it be the way to solve it for everyone (lovers and hates of dependabot)?
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:28, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > @Gary thing is it is not one email per period but a much email as upgrades > per period with dependabot, there is no bulk email feature > > 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:27, Gary Gregory <garydgreg...@gmail.com> a > écrit : > >> On Wed, Dec 29, 2021 at 9:45 AM sebb <seb...@gmail.com> wrote: >> >> > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins <chtom...@gmail.com> wrote: >> > > >> > > Why not just run dependabot weekly. We move slowly enough that weekly >> > currently works. Until we can get more hands on the project, slower >> comms >> > are indeed reasonable…right? >> > >> > Weekly runs won't reduce the number of emails, except where a single >> > dependency has been updated twice in a week. >> > >> >> I'm baffled by your reply: If I get one email a day for a week for a new >> dependency version, that's 7 emails. If I get one email a week for a >> dependency, let me see..., that's one a week. So it's seven times LESS. >> >> Gary >> >> > >> > I don't see how it is possible to reduce the noise from dependabot. >> > >> > > -Rob >> > > >> > > > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > > > >> > > > Saving dev/human resources is about having a CI, all mentionned >> > plugins of >> > > > the thread support it properly while cronned. >> > > > Difference is the scope of the checks: CVE only, all deps, plugins >> and >> > code >> > > > (which is where most people don't like since it is trivial to have >> > false >> > > > positive and dependabot falls there). >> > > > >> > > > I agree CVE are a crucial topic but dependabot is NOT done for them, >> > it is >> > > > done for dependencies as a whole and is full of bugs so until it is >> > refined >> > > > to be more relevant and bulked differently (maybe *1* mail a week) >> > then it >> > > > is not an option for an everyday work 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 à 15:18, Gary Gregory <garydgreg...@gmail.com> >> a >> > > >> écrit : >> > > >> >> > > >>> 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?* >> > > >> >> > > >> 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 >> > >> > >> >
