Re: can we get rid of dependabot?

2021-12-29 Thread Phil Steitz
On 12/29/21 8:43 AM, sebb wrote: On Wed, 29 Dec 2021 at 14:53, Gary Gregory wrote: On Wed, Dec 29, 2021 at 9:42 AM sebb wrote: On Wed, 29 Dec 2021 at 14:18, Gary Gregory wrote: On Wed, Dec 29, 2021 at 9:07 AM sebb wrote: On Wed, 29 Dec 2021 at 13:54, Gary Gregory wrote: One

Re: can we get rid of dependabot?

2021-12-29 Thread Matt Sicker
All these version pins, notification settings, etc., are all configurable in the Dependabot config file. -- Matt Sicker > On Dec 29, 2021, at 09:22, Romain Manni-Bucau wrote: > > @Rob: not sure dependabot would get commits permissions anytime soon, it is > really an automotion thing on one

Re: Has Dependabot alerted us to any security issues?

2021-12-29 Thread sebb
On Wed, 29 Dec 2021 at 14:49, Xeno Amess wrote: > > log4j2 recently, in vfs... Log4j2 would have been known about without Dependabot. > sebb 于2021年12月29日周三 22:48写道: > > > Genuine question: has Dependabot alerted us to any security issues? > > > > If so which ones, and was it the only alert

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
I still yet don’t see how thoughtful automation using dependabot doesn’t win out. So the idea behind using a double negative in a sentence like above, is to imply that there is more than just a “yes/no” answer to the question. There is the beginnings (a few choices) of a veritable continuum

Re: can we get rid of dependabot?

2021-12-29 Thread sebb
On Wed, 29 Dec 2021 at 14:53, Gary Gregory wrote: > > On Wed, Dec 29, 2021 at 9:42 AM sebb wrote: > > > On Wed, 29 Dec 2021 at 14:18, Gary Gregory wrote: > > > > > > On Wed, Dec 29, 2021 at 9:07 AM sebb wrote: > > > > > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory > > wrote: > > > > > > > >

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
> On Dec 29, 2021, at 10:29 AM, Matt Benson wrote: > > On Wed, Dec 29, 2021, 9:21 AM Mark Thomas wrote: > >>> On 29/12/2021 15:04, Gary Gregory wrote: On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins wrote: >>> Why not just run dependabot weekly. We move slowly enough that weekly

Re: can we get rid of dependabot?

2021-12-29 Thread Matt Benson
On Wed, Dec 29, 2021, 9:27 AM Gary Gregory wrote: > On Wed, Dec 29, 2021 at 9:45 AM sebb wrote: > > > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins wrote: > > > > > > Why not just run dependabot weekly. We move slowly enough that weekly > > currently works. Until we can get more hands on the

Re: can we get rid of dependabot?

2021-12-29 Thread sebb
On Wed, 29 Dec 2021 at 15:32, Romain Manni-Bucau wrote: > > 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

Re: can we get rid of dependabot?

2021-12-29 Thread Romain Manni-Bucau
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

Re: can we get rid of dependabot?

2021-12-29 Thread Matt Benson
On Wed, Dec 29, 2021, 9:21 AM Mark Thomas wrote: > On 29/12/2021 15:04, Gary Gregory wrote: > > On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins wrote: > > > >> Why not just run dependabot weekly. We move slowly enough that weekly > >> currently works. Until we can get more hands on the project,

Re: can we get rid of dependabot?

2021-12-29 Thread Romain Manni-Bucau
@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 | Blog | Old Blog |

Re: can we get rid of dependabot?

2021-12-29 Thread Gary Gregory
On Wed, Dec 29, 2021 at 9:45 AM sebb wrote: > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins 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

Re: can we get rid of dependabot?

2021-12-29 Thread Romain Manni-Bucau
@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

Re: can we get rid of dependabot?

2021-12-29 Thread Mark Thomas
On 29/12/2021 15:04, Gary Gregory wrote: On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins 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? I would be OK with it

Re: [VOTE] Release Apache Commons JCS 3.1 based on RC1

2021-12-29 Thread Thomas Vandahl
> Am 29.12.2021 um 16:06 schrieb Gary Gregory : > > Is this test failure being addressed? Well, "addressed" is a big word for what I'm currently trying. "looked at" is closer to what happens. Bye, Thomas - To unsubscribe,

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
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

Re: [VOTE] Release Apache Commons JCS 3.1 based on RC1

2021-12-29 Thread Gary Gregory
FWIW, from the git tag, I run 'mvn clean install' and it passes but I think we should make it easier to make reviewers pass builds since we do not always have a lot of reviewers ;-) Is this test failure being addressed? TY! Gary PS: My set up is: openjdk version "1.8.0_312" OpenJDK Runtime

Re: can we get rid of dependabot?

2021-12-29 Thread Gary Gregory
On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins 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? > I would be OK with it once a week. Gary > > -Rob > > > On

Re: Has Dependabot alerted us to any security issues?

2021-12-29 Thread John Patrick
snyk just looks at security issues, not all avaliable updates. i see dependabot (personally use renovate bot as dependabot has a broken security mode regarding forks, as you can't disable dependabot on a fork), as pro-actively upgrading dependencies, so the older dependency with a security issue

Re: can we get rid of dependabot?

2021-12-29 Thread Gary Gregory
On Wed, Dec 29, 2021 at 9:42 AM sebb wrote: > On Wed, 29 Dec 2021 at 14:18, Gary Gregory wrote: > > > > On Wed, Dec 29, 2021 at 9:07 AM sebb wrote: > > > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory > wrote: > > > > > > > > One critical feature is that dependabot does all the builds for you

Re: Has Dependabot alerted us to any security issues?

2021-12-29 Thread Xeno Amess
log4j2 recently, in vfs... sebb 于2021年12月29日周三 22:48写道: > Genuine question: has Dependabot alerted us to any security issues? > > If so which ones, and was it the only alert mechanism for that issue? > > Sebb > > - > To

Has Dependabot alerted us to any security issues?

2021-12-29 Thread sebb
Genuine question: has Dependabot alerted us to any security issues? If so which ones, and was it the only alert mechanism for that issue? Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional

Re: can we get rid of dependabot?

2021-12-29 Thread sebb
On Wed, 29 Dec 2021 at 14:36, Rob Tompkins 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

Re: can we get rid of dependabot?

2021-12-29 Thread sebb
On Wed, 29 Dec 2021 at 14:18, Gary Gregory wrote: > > On Wed, Dec 29, 2021 at 9:07 AM sebb wrote: > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory wrote: > > > > > > One critical feature is that dependabot does all the builds for you on > > > GitHub Actions, this is an enormous time and

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
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? -Rob > On Dec 29, 2021, at 9:31 AM, Romain Manni-Bucau wrote: > > Saving dev/human resources is about having a CI, all

Re: can we get rid of dependabot?

2021-12-29 Thread Romain Manni-Bucau
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

Re: can we get rid of dependabot?

2021-12-29 Thread Gary Gregory
On Wed, Dec 29, 2021 at 9:07 AM sebb wrote: > On Wed, 29 Dec 2021 at 13:54, Gary Gregory 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

Re: can we get rid of dependabot?

2021-12-29 Thread sebb
On Wed, 29 Dec 2021 at 13:54, Gary Gregory 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

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
> On Dec 29, 2021, at 8:54 AM, Gary Gregory wrote: > > One critical feature is that dependabot does all the builds for you on > GitHub Actions, this is an enormous time and resource saver! > Ding ding ding ding….we have a winner. We just don’t yet know how to implement. > Gary > >> On

Re: can we get rid of dependabot?

2021-12-29 Thread Gary Gregory
One critical feature is that dependabot does all the builds for you on GitHub Actions, this is an enormous time and resource saver! Gary On Wed, Dec 29, 2021, 08:51 Rob Tompkins wrote: > > > > On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau > wrote: > > > > @Rob: dependabot is mainly about

Re: can we get rid of dependabot?

2021-12-29 Thread Romain Manni-Bucau
@Rob: dependabot is mainly about dependencies upgrades and it is also why it is so chatty and has so much false positives. 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

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
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

Re: can we get rid of dependabot?

2021-12-29 Thread Rob Tompkins
> On Dec 28, 2021, at 1:57 PM, Gary Gregory wrote: > > Please no. Dependabot is a key tool for me. Inbox rules should be able to > help you depending on your client. Huge +1 I think we need to help GitHub figure out how to make it better. -Rob > > Someone had suggested creating a new

Re: can we get rid of dependabot?

2021-12-29 Thread Gilles Sadowski
Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl 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

Re: can we get rid of dependabot?

2021-12-29 Thread Thomas Vandahl
+1 Thank you, Phil. This thing is a P.I.T.A. > Am 28.12.2021 um 19:20 schrieb Phil Steitz : > > 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