Re: [all] Dependabot PRs

[Stefan Bodewig]

On 2020-07-23, Oliver Heger wrote:

> Am 22.07.20 um 18:28 schrieb Stefan Bodewig:
>> On 2020-07-22, Rob Tompkins wrote:

>>> I’m happy to merge them….will get to them by tomorrow morning ok?

>> Personally I don't see any value for our downstream users if we update
>> our dependencies without actually needing an update - with the exception
>> of security updates. I don't like the idea of forcing our users to
>> update a different dependency just because they update our component, it
>> should be their choice when to update what.

> Stefan has a valid point here IMHO.

Thank you ;-)

I intend to raise a separate thread for this later as I'm afraid this
thread has been burnt by a different discussion.

> From out user's POV, our components are in some sense "more
> compatible" if they reference the oldest possible version of a
> dependency rather than the newest one.

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Oliver Heger]

Am 22.07.20 um 18:28 schrieb Stefan Bodewig:
> On 2020-07-22, Rob Tompkins wrote:
> 
>> I’m happy to merge them….will get to them by tomorrow morning ok?
> 
> TBH I'd prefer to turn them off and reject the PRs.
> 
> Personally I don't see any value for our downstream users if we update
> our dependencies without actually needing an update - with the exception
> of security updates. I don't like the idea of forcing our users to
> update a different dependency just because they update our component, it
> should be their choice when to update what.
> 
> Of course this is just my opinion and I'm not exactly known as somebody
> who embraces the idea of automatic resolution of transitive dependencies
> in the first place ;-)

Stefan has a valid point here IMHO. From out user's POV, our components
are in some sense "more compatible" if they reference the oldest
possible version of a dependency rather than the newest one.

If we upgrade dependencies rather aggressively, it would be nice to
document a version range for the dependencies that has been tested. This
could save users from possible version conflicts with other 3rd party
dependencies. Creating such a documentation is probably hard though; I
do not think that this can be automated.

Oliver

> 
> Stefan
> 
> -
> 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

Re: [all] Dependabot PRs

[Rob Tompkins]

Also, it occurs to me that these emails are all valid issues based upon valid 
work. Yes they’re automated, but they’re also going to the list for automated 
messages, namely `comm...@commons.apache.org 
`. If that’s too much to handle you can 
unsubscribe from that list. I personally like seeing volumes of work getting 
done on the project. It means that we’re moving forward in a healthy fashion.

-Rob

> On Jul 23, 2020, at 7:02 AM, Rob Tompkins  wrote:
> 
> 
> 
>> On Jul 23, 2020, at 5:25 AM, Torsten Curdt  wrote:
>> 
>> On Thu, Jul 23, 2020 at 4:40 AM Rob Tompkins  wrote:
>> 
>>> Guys...let’s not argue like this. It gets us nowhere.
>>> 
>> 
>> You are right.
>> I can see that it is indeed pointless and will not waste more time on it.
>> Sorry, about adding to the noise.
> 
> 
> It’s ok. I appreciate the conversation. Thanks for the understanding.
> 
> Cheers,
> -Rob

Re: [all] Dependabot PRs

[Rob Tompkins]

> On Jul 23, 2020, at 5:25 AM, Torsten Curdt  wrote:
> 
> On Thu, Jul 23, 2020 at 4:40 AM Rob Tompkins  wrote:
> 
>> Guys...let’s not argue like this. It gets us nowhere.
>> 
> 
> You are right.
> I can see that it is indeed pointless and will not waste more time on it.
> Sorry, about adding to the noise.


It’s ok. I appreciate the conversation. Thanks for the understanding.

Cheers,
-Rob
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Torsten Curdt]

On Thu, Jul 23, 2020 at 4:40 AM Rob Tompkins  wrote:

> Guys...let’s not argue like this. It gets us nowhere.
>

You are right.
I can see that it is indeed pointless and will not waste more time on it.
Sorry, about adding to the noise.

Re: [all] Dependabot PRs

[Rob Tompkins]

Guys...let’s not argue like this. It gets us nowhere. 

-Rob

> On Jul 22, 2020, at 10:16 PM, Gilles Sadowski  wrote:
> 
> 2020-07-23 3:09 UTC+02:00, Torsten Curdt :
>>> 
>>> 
 TBH not in terms of your "you act, and I must react" argument.
>>> 
>>> It was not an argument, but a statement of fact.
>>> 
>> 
>> Well, it "must react" feels a bit loaded.
> 
> Perhaps another (?) misunderstanding here.
> The action came before the explanation, and the only possibility
> was to deal synchronously (!) with the consequences.
> [On some relatively old systems, it does not take 10s to delete
> those hundreds of emails.]
> 
>> And I see two possible actions here:
>> 
>> 1. A person of another project doing a release, triggering a bot to notify
>> us and even create a PR.This also results in a message to the list.
>> 2. A person enabling the bot, causing a one-time "flood" of messages to the
>> list.
>> 
>> I assume you were referring to 2.?
> 
> Yes.
> 
>> You were outraged you had to delete those messages?
> 
> No.
> As said, this time it showed that the problem is getting
> worse by the days (perhaps because most people have
> efficient ways to discard those dumb messages).
> 
>> 
>> Did you missed/skip the start of the thread, where I merely
>>> asked what was the flood (like I don't think we've have ever
>>> seen) about?
>>> 
>> 
>> I did indeed miss
> 
> So why assume ill intent?
> 
>> that - but I am not searching the archives for reading up
>> on the exact wording.
> 
> Here you are.
> I said (2nd message in this thread):
> ---CUT---
> Hello.
> 
> What's this flood of emails about?
> ---CUT---
> 
> In the hope to get a plain explanation of what was attempted
> and why.
> 
> Just got (3rd message):
> ---CUT---
> Just read them!
> ---CUT---
> 
>> Nevertheless...
>> 
>> 
>> 
>>> My remark came after getting a blunt reply that I should
>>> read those messages (though they obviously weren't even
>>> fitted to be read in a mail client) and go figure out (after the
>>> fact) how to not see them.
>>> 
>> 
>> Maybe the "blunt reply" is the main reason we are still writing here?
> 
> No.  The problem is factual and older.
> Just the final straw...
> 
>> In a way I hope it is that
> 
> I hope that we somewhat converge now.
> 
>> - and not deletion of a bunch of emails.
> 
> I do that everyday.
> But I see a (big) difference in deleting potentially useful
> mails from plain redundant ones.
> 
>> 
>> Care to share your experience of dealing with those hundreds
>>> of bot posts?
>>> 
>> 
>> Sure. I realized what it is, then I did a search/filter to select them, and
>> deleted them.
> 
> Confirming what I thought.
> This time I thought that I should brought up the issue instead
> of sweeping it under the rug.
> 
>> As said before that took me probably 10s.
>> I am more concerned about the time I spent contributing to this thread.
> 
> Thanks for the contribution!
> From my end, I sincerely did not expect my concern to be
> negated on the premise that it is easy (in some mail clients)
> to filter them out, rather than question the utility of ever
> increasing the production of mails that (every)one is
> immediately deleting.
> 
>> 
>> Mine is that either I can get useful info out of them, or I should
>>> not receive them.  [Getting automatic messages, and having
>>> them thrown away automatically upon reception seems like a
>>> useless dissipation of heat.]
>>> 
>> 
>> Oh, I find them very useful.
> 
> But you deleted them...
> 
>> How are they not?
>> And it's not like they get sent out like that every day.
> 
> Back to the non-issue of this one-time flood?
> Issue is that there was no prior discussion.
> And *everyday*, I get way more than 100 messages from
> this project, probably 90% from issues@ from which less than
> 10% are not redundant or trivial.
> 
> This could be handled rather than denied.
> 
>> The problem is that indeed some messages from "issues@" are
>>> useful (otherwise I would have unsubscribed already...).
>>> 
>> 
>> Well, the same goes for dependency upgrades.
>> 
> 
> Perhaps.
> As said in the beginning of this message and this thread,
> it would have been _nice_ to _first_ post to "dev@" so that
> the pros and cons are presented.
> 
> Again, it is obvious from the contents of those emails that
> the primary means to view it is _not_ in an email; hence I
> deduce (perhaps hastily) that it is possible to get the pros
> (get the info to those interested GH users) without the cons
> (relay to "issues@").
> At least, the feature is half-baked or maybe badly configured,
> i.e. all the more reason to not make bulk changes.
> 
> Gilles
> 
> -
> 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: 

Re: [all] Dependabot PRs

[Gilles Sadowski]

2020-07-23 3:09 UTC+02:00, Torsten Curdt :
>>
>>
>> > TBH not in terms of your "you act, and I must react" argument.
>>
>> It was not an argument, but a statement of fact.
>>
>
> Well, it "must react" feels a bit loaded.

Perhaps another (?) misunderstanding here.
The action came before the explanation, and the only possibility
was to deal synchronously (!) with the consequences.
[On some relatively old systems, it does not take 10s to delete
those hundreds of emails.]

> And I see two possible actions here:
>
> 1. A person of another project doing a release, triggering a bot to notify
> us and even create a PR.This also results in a message to the list.
> 2. A person enabling the bot, causing a one-time "flood" of messages to the
> list.
>
> I assume you were referring to 2.?

Yes.

> You were outraged you had to delete those messages?

No.
As said, this time it showed that the problem is getting
worse by the days (perhaps because most people have
efficient ways to discard those dumb messages).

>
> Did you missed/skip the start of the thread, where I merely
>> asked what was the flood (like I don't think we've have ever
>> seen) about?
>>
>
> I did indeed miss

So why assume ill intent?

> that - but I am not searching the archives for reading up
> on the exact wording.

Here you are.
I said (2nd message in this thread):
---CUT---
Hello.

What's this flood of emails about?
---CUT---

In the hope to get a plain explanation of what was attempted
and why.

Just got (3rd message):
---CUT---
Just read them!
---CUT---

> Nevertheless...
>
>
>
>> My remark came after getting a blunt reply that I should
>> read those messages (though they obviously weren't even
>> fitted to be read in a mail client) and go figure out (after the
>> fact) how to not see them.
>>
>
> Maybe the "blunt reply" is the main reason we are still writing here?

No.  The problem is factual and older.
Just the final straw...

> In a way I hope it is that

I hope that we somewhat converge now.

> - and not deletion of a bunch of emails.

I do that everyday.
But I see a (big) difference in deleting potentially useful
mails from plain redundant ones.

>
> Care to share your experience of dealing with those hundreds
>> of bot posts?
>>
>
> Sure. I realized what it is, then I did a search/filter to select them, and
> deleted them.

Confirming what I thought.
This time I thought that I should brought up the issue instead
of sweeping it under the rug.

> As said before that took me probably 10s.
> I am more concerned about the time I spent contributing to this thread.

Thanks for the contribution!
>From my end, I sincerely did not expect my concern to be
negated on the premise that it is easy (in some mail clients)
to filter them out, rather than question the utility of ever
increasing the production of mails that (every)one is
immediately deleting.

>
> Mine is that either I can get useful info out of them, or I should
>> not receive them.  [Getting automatic messages, and having
>> them thrown away automatically upon reception seems like a
>> useless dissipation of heat.]
>>
>
> Oh, I find them very useful.

But you deleted them...

> How are they not?
> And it's not like they get sent out like that every day.

Back to the non-issue of this one-time flood?
Issue is that there was no prior discussion.
And *everyday*, I get way more than 100 messages from
this project, probably 90% from issues@ from which less than
10% are not redundant or trivial.

This could be handled rather than denied.

> The problem is that indeed some messages from "issues@" are
>> useful (otherwise I would have unsubscribed already...).
>>
>
> Well, the same goes for dependency upgrades.
>

Perhaps.
As said in the beginning of this message and this thread,
it would have been _nice_ to _first_ post to "dev@" so that
the pros and cons are presented.

Again, it is obvious from the contents of those emails that
the primary means to view it is _not_ in an email; hence I
deduce (perhaps hastily) that it is possible to get the pros
(get the info to those interested GH users) without the cons
(relay to "issues@").
At least, the feature is half-baked or maybe badly configured,
i.e. all the more reason to not make bulk changes.

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Torsten Curdt]

>
>
> > TBH not in terms of your "you act, and I must react" argument.
>
> It was not an argument, but a statement of fact.
>

Well, it "must react" feels a bit loaded.
And I see two possible actions here:

1. A person of another project doing a release, triggering a bot to notify
us and even create a PR.This also results in a message to the list.
2. A person enabling the bot, causing a one-time "flood" of messages to the
list.

I assume you were referring to 2.?
You were outraged you had to delete those messages?


Did you missed/skip the start of the thread, where I merely
> asked what was the flood (like I don't think we've have ever
> seen) about?
>

I did indeed miss that - but I am not searching the archives for reading up
on the exact wording.
Nevertheless...



> My remark came after getting a blunt reply that I should
> read those messages (though they obviously weren't even
> fitted to be read in a mail client) and go figure out (after the
> fact) how to not see them.
>

Maybe the "blunt reply" is the main reason we are still writing here?
In a way I hope it is that - and not deletion of a bunch of emails.


Care to share your experience of dealing with those hundreds
> of bot posts?
>

Sure. I realized what it is, then I did a search/filter to select them, and
deleted them.
As said before that took me probably 10s.
I am more concerned about the time I spent contributing to this thread.


Mine is that either I can get useful info out of them, or I should
> not receive them.  [Getting automatic messages, and having
> them thrown away automatically upon reception seems like a
> useless dissipation of heat.]
>

Oh, I find them very useful. How are they not?
And it's not like they get sent out like that every day.


The problem is that indeed some messages from "issues@" are
> useful (otherwise I would have unsubscribed already...).
>

Well, the same goes for dependency upgrades.

Re: [all] Dependabot PRs

[Gilles Sadowski]

2020-07-23 1:37 UTC+02:00, Torsten Curdt :
> On Thu, Jul 23, 2020 at 12:51 AM Gilles Sadowski 
> wrote:
>
>> 2020-07-23 0:14 UTC+02:00, Torsten Curdt :
>> >>
>> >> You act, and I must react?
>> >> Do I really have to spell it in even more words than
>> >> above?
>> >>
>> >
>> > You just sent me a message I didn't want - and I need to delete it now
>> > ;)
>> >
>> > But tongue in cheek aside. We are on a dev list.
>> > Commits, issues all generate traffic that are caused by other people.
>>
>> I'm sure that you see the difference between a bot-generated
>> message and a post by a human.
>>
>
> TBH not in terms of your "you act, and I must react" argument.

It was not an argument, but a statement of fact.
Did you missed/skip the start of the thread, where I merely
asked what was the flood (like I don't think we've have ever
seen) about?
My remark came after getting a blunt reply that I should
read those messages (though they obviously weren't even
fitted to be read in a mail client) and go figure out (after the
fact) how to not see them.

>> If you are not willing to deal with that, we might have very different
>> > expectations.
>>
>> My expectations did not change, as I explain in the [VOTE] thread
>> about the purposes of "issues@".
>>
>
> I didn't say they changed, but they do seem to be very different from mine.
>

Care to share your experience of dealing with those hundreds
of bot posts?
Mine is that either I can get useful info out of them, or I should
not receive them.  [Getting automatic messages, and having
them thrown away automatically upon reception seems like a
useless dissipation of heat.]

The problem is that indeed some messages from "issues@" are
useful (otherwise I would have unsubscribed already...).

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Gary Gregory]

On Wed, Jul 22, 2020 at 6:51 PM Gilles Sadowski 
wrote:

> 2020-07-23 0:14 UTC+02:00, Torsten Curdt :
> >>
> >> You act, and I must react?
> >> Do I really have to spell it in even more words than
> >> above?
> >>
> >
> > You just sent me a message I didn't want - and I need to delete it now ;)
> >
> > But tongue in cheek aside. We are on a dev list.
> > Commits, issues all generate traffic that are caused by other people.
>
> I'm sure that you see the difference between a bot-generated
> message and a post by a human.
>
> > If you are not willing to deal with that, we might have very different
> > expectations.
>
> My expectations did not change, as I explain in the [VOTE] thread
> about the purposes of "issues@".
>

I've always considered issues@ for automated emails, first from Jira, then
svn, then git. Have you ever seen a human post to @issues?

Gary

>
> I've no problem with people wanting more bot-generated email,
> but then *they* change their expectations, and they should adapt
> (in this instance, by using a new ML).
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Dependabot PRs

[Torsten Curdt]

On Thu, Jul 23, 2020 at 12:51 AM Gilles Sadowski 
wrote:

> 2020-07-23 0:14 UTC+02:00, Torsten Curdt :
> >>
> >> You act, and I must react?
> >> Do I really have to spell it in even more words than
> >> above?
> >>
> >
> > You just sent me a message I didn't want - and I need to delete it now ;)
> >
> > But tongue in cheek aside. We are on a dev list.
> > Commits, issues all generate traffic that are caused by other people.
>
> I'm sure that you see the difference between a bot-generated
> message and a post by a human.
>

TBH not in terms of your "you act, and I must react" argument.


> If you are not willing to deal with that, we might have very different
> > expectations.
>
> My expectations did not change, as I explain in the [VOTE] thread
> about the purposes of "issues@".
>

I didn't say they changed, but they do seem to be very different from mine.

Re: [all] Dependabot PRs

[Gilles Sadowski]

2020-07-23 0:14 UTC+02:00, Torsten Curdt :
>>
>> You act, and I must react?
>> Do I really have to spell it in even more words than
>> above?
>>
>
> You just sent me a message I didn't want - and I need to delete it now ;)
>
> But tongue in cheek aside. We are on a dev list.
> Commits, issues all generate traffic that are caused by other people.

I'm sure that you see the difference between a bot-generated
message and a post by a human.

> If you are not willing to deal with that, we might have very different
> expectations.

My expectations did not change, as I explain in the [VOTE] thread
about the purposes of "issues@".

I've no problem with people wanting more bot-generated email,
but then *they* change their expectations, and they should adapt
(in this instance, by using a new ML).

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Torsten Curdt]

>
> You act, and I must react?
> Do I really have to spell it in even more words than
> above?
>

You just sent me a message I didn't want - and I need to delete it now ;)

But tongue in cheek aside. We are on a dev list.
Commits, issues all generate traffic that are caused by other people.
If you are not willing to deal with that, we might have very different
expectations.

Re: [all] Dependabot PRs

[Gilles Sadowski]

2020-07-22 21:21 UTC+02:00, Gary Gregory :
> On Wed, Jul 22, 2020 at 12:39 PM Rob Tompkins  wrote:
>
>>
>>
>> > On Jul 22, 2020, at 11:53 AM, Gilles Sadowski 
>> wrote:
>> >
>> > Le mer. 22 juil. 2020 à 17:45, Gary Gregory > > a écrit :
>> >>
>> >> You can ignore those
>> >
>> > How can I ignore stuff that gets pushed into my mailbox?
>> > Spammers could argue in the same way.
>> > I've had to click on each of these automated messages to
>> > delete them.  IMHO, the consequences of new settings
>> > should be tested on a _small_ scale, with a suggestion of
>> > how to avoid the nuisance.
>>
>> Tolerance maybe?
>>
>
> Email rules? Most clients have some.

You act, and I must react?
Do I really have to spell it in even more words than
above?

Gilles

> > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Rob Tompkins]

> On Jul 22, 2020, at 3:26 PM, Gary Gregory  wrote:
> 
> On Wed, Jul 22, 2020 at 1:58 PM Torsten Curdt  wrote:
> 
>>> 
>>> 
>> You can ignore those
> 
> How can I ignore stuff that gets pushed into my mailbox?
> Spammers could argue in the same way.
> I've had to click on each of these automated messages to
> delete them.  IMHO, the consequences of new settings
> should be tested on a _small_ scale, with a suggestion of
> how to avoid the nuisance.
 
 Tolerance maybe?
>>> 
>>> Do you mean that I would be intolerant by reminding
>>> that such changes should perhaps be discussed first?
>>> That would be amazing.
>>> The ratio of useful/meaningful/human messages
>>> received on this ML steadily decreases.
>>> 
>> 
>> Geez, could everyone please take a deep breath before replying?
>> 
>> I've also been annoyed by jira spam during the years and deal with it.
>> This is a dev mailing list. Deleting those emails with an easy to match
>> subject should take 10s.
>> 
>> And while I personally find it is useful (at least for minor releases),
>> I also would have preferred, if this was discussed first.
>> Not a great way to approach such a change.
>> 
> 
> Then let's blame yours truly. I saw a PR to add Dependabot to Lang, I
> merged it. I had seen similar PRs in the past that I had then ignored. No
> more. Instead of watching PR after PR come in for each Commons component, I
> just did it for components that already had GitHub builds. Ideally, I'll
> add a few GitHub builds for some other components.
> 
> I'm also thinking of dropping Travis-CI builds in favor of GitHub builds,
> less to maintain, even though it's not much, and no, I do not plan on
> bothering with the new Jenkins system at  https://ci-builds.apache.org/ 
> because
> Jenkins has been a pain to deal with (for me) in the past. So we can
> discuss that as well.

I’m a +1 on going all in on github’s CICD tooling

-Rob

> 
> Gary
> 
> 
>> cheers,
>> Torsten
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Gary Gregory]

On Wed, Jul 22, 2020 at 1:58 PM Torsten Curdt  wrote:

> >
> >
> > > >> You can ignore those
> > > >
> > > > How can I ignore stuff that gets pushed into my mailbox?
> > > > Spammers could argue in the same way.
> > > > I've had to click on each of these automated messages to
> > > > delete them.  IMHO, the consequences of new settings
> > > > should be tested on a _small_ scale, with a suggestion of
> > > > how to avoid the nuisance.
> > >
> > > Tolerance maybe?
> >
> > Do you mean that I would be intolerant by reminding
> > that such changes should perhaps be discussed first?
> > That would be amazing.
> > The ratio of useful/meaningful/human messages
> > received on this ML steadily decreases.
> >
>
> Geez, could everyone please take a deep breath before replying?
>
> I've also been annoyed by jira spam during the years and deal with it.
> This is a dev mailing list. Deleting those emails with an easy to match
> subject should take 10s.
>
> And while I personally find it is useful (at least for minor releases),
> I also would have preferred, if this was discussed first.
> Not a great way to approach such a change.
>

Then let's blame yours truly. I saw a PR to add Dependabot to Lang, I
merged it. I had seen similar PRs in the past that I had then ignored. No
more. Instead of watching PR after PR come in for each Commons component, I
just did it for components that already had GitHub builds. Ideally, I'll
add a few GitHub builds for some other components.

I'm also thinking of dropping Travis-CI builds in favor of GitHub builds,
less to maintain, even though it's not much, and no, I do not plan on
bothering with the new Jenkins system at  https://ci-builds.apache.org/ because
Jenkins has been a pain to deal with (for me) in the past. So we can
discuss that as well.

Gary


> cheers,
> Torsten
>

Re: [all] Dependabot PRs

[Gary Gregory]

On Wed, Jul 22, 2020 at 12:39 PM Rob Tompkins  wrote:

>
>
> > On Jul 22, 2020, at 11:53 AM, Gilles Sadowski 
> wrote:
> >
> > Le mer. 22 juil. 2020 à 17:45, Gary Gregory  > a écrit :
> >>
> >> You can ignore those
> >
> > How can I ignore stuff that gets pushed into my mailbox?
> > Spammers could argue in the same way.
> > I've had to click on each of these automated messages to
> > delete them.  IMHO, the consequences of new settings
> > should be tested on a _small_ scale, with a suggestion of
> > how to avoid the nuisance.
>
> Tolerance maybe?
>

Email rules? Most clients have some.

Gary


>
> -Rob
>
> >
> > Gilles
> >
> >> if you prefer to look at the GitHub PRs instead.
> >> That's what I do.
> >>
> >> Gary
> >>
> >> On Wed, Jul 22, 2020 at 11:20 AM Rob Tompkins 
> wrote:
> >>
> >>> I think that Gary tuerned on some github automation to help us stay up
> to
> >>> date with dependencies.
> >>>
> >>> -Rob
> >>>
>  On Jul 22, 2020, at 10:43 AM, Gilles Sadowski 
> >>> wrote:
> 
>  Hello.
> 
>  What's this flood of emails about?
> 
>  Gilles
> 
>  Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a
> >>> écrit :
> >
> > I’m happy to merge them….will get to them by tomorrow morning ok?
> >
> > -Rob
> 
>  -
>  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  dev-unsubscr...@commons.apache.org>
> > For additional commands, e-mail: dev-h...@commons.apache.org  dev-h...@commons.apache.org>
>

Re: [all] Dependabot PRs

[Torsten Curdt]

>
>
> > >> You can ignore those
> > >
> > > How can I ignore stuff that gets pushed into my mailbox?
> > > Spammers could argue in the same way.
> > > I've had to click on each of these automated messages to
> > > delete them.  IMHO, the consequences of new settings
> > > should be tested on a _small_ scale, with a suggestion of
> > > how to avoid the nuisance.
> >
> > Tolerance maybe?
>
> Do you mean that I would be intolerant by reminding
> that such changes should perhaps be discussed first?
> That would be amazing.
> The ratio of useful/meaningful/human messages
> received on this ML steadily decreases.
>

Geez, could everyone please take a deep breath before replying?

I've also been annoyed by jira spam during the years and deal with it.
This is a dev mailing list. Deleting those emails with an easy to match
subject should take 10s.

And while I personally find it is useful (at least for minor releases),
I also would have preferred, if this was discussed first.
Not a great way to approach such a change.

cheers,
Torsten

Re: [all] Dependabot PRs

[Gilles Sadowski]

Le mer. 22 juil. 2020 à 18:39, Rob Tompkins  a écrit :
>
>
>
> > On Jul 22, 2020, at 11:53 AM, Gilles Sadowski  wrote:
> >
> > Le mer. 22 juil. 2020 à 17:45, Gary Gregory  > > a écrit :
> >>
> >> You can ignore those
> >
> > How can I ignore stuff that gets pushed into my mailbox?
> > Spammers could argue in the same way.
> > I've had to click on each of these automated messages to
> > delete them.  IMHO, the consequences of new settings
> > should be tested on a _small_ scale, with a suggestion of
> > how to avoid the nuisance.
>
> Tolerance maybe?

Do you mean that I would be intolerant by reminding
that such changes should perhaps be discussed first?
That would be amazing.
The ratio of useful/meaningful/human messages
received on this ML steadily decreases.

Gilles

>
> -Rob
>
> >
> > Gilles
> >
> >> if you prefer to look at the GitHub PRs instead.
> >> That's what I do.
> >>
> >> Gary
> >>
> >> On Wed, Jul 22, 2020 at 11:20 AM Rob Tompkins  wrote:
> >>
> >>> I think that Gary tuerned on some github automation to help us stay up to
> >>> date with dependencies.
> >>>
> >>> -Rob
> >>>
>  On Jul 22, 2020, at 10:43 AM, Gilles Sadowski 
> >>> wrote:
> 
>  Hello.
> 
>  What's this flood of emails about?
> 
>  Gilles
> 
>  Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a
> >>> écrit :
> >
> > I’m happy to merge them….will get to them by tomorrow morning ok?
> >
> > -Rob

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Stefan Bodewig]

On 2020-07-22, Rob Tompkins wrote:

> I’m happy to merge them….will get to them by tomorrow morning ok?

TBH I'd prefer to turn them off and reject the PRs.

Personally I don't see any value for our downstream users if we update
our dependencies without actually needing an update - with the exception
of security updates. I don't like the idea of forcing our users to
update a different dependency just because they update our component, it
should be their choice when to update what.

Of course this is just my opinion and I'm not exactly known as somebody
who embraces the idea of automatic resolution of transitive dependencies
in the first place ;-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependabot PRs

[Rob Tompkins]

> On Jul 22, 2020, at 11:53 AM, Gilles Sadowski  wrote:
> 
> Le mer. 22 juil. 2020 à 17:45, Gary Gregory  > a écrit :
>> 
>> You can ignore those
> 
> How can I ignore stuff that gets pushed into my mailbox?
> Spammers could argue in the same way.
> I've had to click on each of these automated messages to
> delete them.  IMHO, the consequences of new settings
> should be tested on a _small_ scale, with a suggestion of
> how to avoid the nuisance.

Tolerance maybe?

-Rob

> 
> Gilles
> 
>> if you prefer to look at the GitHub PRs instead.
>> That's what I do.
>> 
>> Gary
>> 
>> On Wed, Jul 22, 2020 at 11:20 AM Rob Tompkins  wrote:
>> 
>>> I think that Gary tuerned on some github automation to help us stay up to
>>> date with dependencies.
>>> 
>>> -Rob
>>> 
 On Jul 22, 2020, at 10:43 AM, Gilles Sadowski 
>>> wrote:
 
 Hello.
 
 What's this flood of emails about?
 
 Gilles
 
 Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a
>>> écrit :
> 
> I’m happy to merge them….will get to them by tomorrow morning ok?
> 
> -Rob
 
 -
 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 
> 

Re: [all] Dependabot PRs

[Gilles Sadowski]

Le mer. 22 juil. 2020 à 17:45, Gary Gregory  a écrit :
>
> You can ignore those

How can I ignore stuff that gets pushed into my mailbox?
Spammers could argue in the same way.
I've had to click on each of these automated messages to
delete them.  IMHO, the consequences of new settings
should be tested on a _small_ scale, with a suggestion of
how to avoid the nuisance.

Gilles

> if you prefer to look at the GitHub PRs instead.
> That's what I do.
>
> Gary
>
> On Wed, Jul 22, 2020 at 11:20 AM Rob Tompkins  wrote:
>
> > I think that Gary tuerned on some github automation to help us stay up to
> > date with dependencies.
> >
> > -Rob
> >
> > > On Jul 22, 2020, at 10:43 AM, Gilles Sadowski 
> > wrote:
> > >
> > > Hello.
> > >
> > > What's this flood of emails about?
> > >
> > > Gilles
> > >
> > > Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a
> > écrit :
> > >>
> > >> I’m happy to merge them….will get to them by tomorrow morning ok?
> > >>
> > >> -Rob
> > >
> > > -
> > > 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

Re: [all] Dependabot PRs

[Gary Gregory]

You can ignore those if you prefer to look at the GitHub PRs instead.
That's what I do.

Gary

On Wed, Jul 22, 2020 at 11:20 AM Rob Tompkins  wrote:

> I think that Gary tuerned on some github automation to help us stay up to
> date with dependencies.
>
> -Rob
>
> > On Jul 22, 2020, at 10:43 AM, Gilles Sadowski 
> wrote:
> >
> > Hello.
> >
> > What's this flood of emails about?
> >
> > Gilles
> >
> > Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a
> écrit :
> >>
> >> I’m happy to merge them….will get to them by tomorrow morning ok?
> >>
> >> -Rob
> >
> > -
> > 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
>
>

Re: [all] Dependabot PRs

[Gilles Sadowski]

Le mer. 22 juil. 2020 à 17:19, Gary Gregory  a écrit :
>
> On Wed, Jul 22, 2020 at 11:02 AM Gilles Sadowski 
> wrote:
>
> > Hello.
> >
> > What's this flood of emails about?
> >
>
> Just read them!

I did a couple, and this is not really helpful:
---CUT---
dependabot[bot] opened a new pull request #11:
URL: https://github.com/apache/commons-logging/pull/11


   Bumps [junit](https://github.com/junit-team/junit4) from 3.8.1 to 4.13.
   
   Release notes
   Sourced from https://github.com/junit-team/junit4/releases;>junit's
releases.
   
   JUnit 4.13
   Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md;>release
notes for details.
   JUnit 4.13 RC 2
   Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release
notes for details.
   JUnit 4.13 RC 1
   Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release
notes for details.
   JUnit 4.13 Beta 3
   Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release
notes for details.
   JUnit 4.13 Beta 2
   Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release
notes for details.
   JUnit 4.13 Beta 1
   Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes;>release
notes for details.
   JUnit 4.12
   Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md;>release
notes for details.
   JUnit 4.12 Beta 3
   Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md;>release
notes for details.
   JUnit 4.12 Beta 2
   No release notes provided.
   JUnit 4.12 Beta 1
   No release notes provided.
   JUnit 4.11
   No release notes provided.
   
   
   
   Changelog
   Sourced from https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.md;>junit's
changelog.
   
   Summary of changes in version 4.13
   Assertions
   [Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1054;>#1054:](https://github-redirect.dependabot.com/junit-team/junit/pull/1054;>junit-team/junit#1054)
Improved error message for assertArrayEquals when
multi-dimensional arrays have different lengths
   Previously, JUnit's assertion error message would indicate only
that some array lengths x and y were unequal,
without indicating whether this pertained to the outer array or some
nested array. Now, in case of a length mismatch between two nested
arrays, JUnit will tell at which indices they reside.
   [Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1154;>#1154](https://github-redirect.dependabot.com/junit-team/junit/pull/1154;>junit-team/junit#1154)
and https://github-redirect.dependabot.com/junit-team/junit/pull/1504;>#1504
Add assertThrows
   The Assert class now includes methods that can
assert that a given function call (specified, for instance, as a
lambda expression or method reference) results in a particular type of
exception being thrown. In addition it returns the exception that was
thrown, so that further assertions can be made (e.g. to verify that
the message and cause are correct).
   [Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1300;>#1300:](https://github-redirect.dependabot.com/junit-team/junit/pull/1300;>junit-team/junit#1300)
Show contents of actual array when array lengths differ
   Previously, when comparing two arrays which differ in length,
assertArrayEquals() would only report that they differ in
length. Now, it does the usual array comparison even when arrays
differ in length, producing a failure message which combines the
difference in length and the first difference in content. Where the
content is another array, it is described by its type and length.
   [Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1315;>#1315:](https://github-redirect.dependabot.com/junit-team/junit4/pull/1315;>junit-team/junit4#1315)
assertArrayEquals shouldn't throw an NPE when test suites
are compiled/run across versions of junit
   A redundant field, fCause, was removed on v4.12,
and was seemingly harmless because Throwable#initCause()
could directly initialize cause in the constructor.
Unfortunately, this backwards incompatible change got aggravated when
a test class, compiled with the latest (4.12+), ran with an older
version that depended on fCause when building the assertion
messagehttps://github.com/junit-team/junit4/blob/main/doc/#1315-f1;>1.
   This change adds back fCause, and overrides
getCause() to handle forward compatibilityhttps://github.com/junit-team/junit4/blob/main/doc/#1315-f2;>2.
   To ensure serializability of further changes in
ArrayAssertionFailure (until excising these fields by a
major rev), a unit test now runs against v4.11, v4.12 failures,
asserting around #toString/getCause().
   [1] [Issue 

Re: [all] Dependabot PRs

[Gary Gregory]

On Wed, Jul 22, 2020 at 11:02 AM Gilles Sadowski 
wrote:

> Hello.
>
> What's this flood of emails about?
>

Just read them!

Gary


>
> Gilles
>
> Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a écrit :
> >
> > I’m happy to merge them….will get to them by tomorrow morning ok?
> >
> > -Rob
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Dependabot PRs

[Rob Tompkins]

I think that Gary tuerned on some github automation to help us stay up to date 
with dependencies.

-Rob

> On Jul 22, 2020, at 10:43 AM, Gilles Sadowski  wrote:
> 
> Hello.
> 
> What's this flood of emails about?
> 
> Gilles
> 
> Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a écrit :
>> 
>> I’m happy to merge them….will get to them by tomorrow morning ok?
>> 
>> -Rob
> 
> -
> 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

Re: [all] Dependabot PRs

[Gilles Sadowski]

Hello.

What's this flood of emails about?

Gilles

Le mer. 22 juil. 2020 à 16:35, Rob Tompkins  a écrit :
>
> I’m happy to merge them….will get to them by tomorrow morning ok?
>
> -Rob

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[all] Dependabot PRs

[Rob Tompkins]

I’m happy to merge them….will get to them by tomorrow morning ok?

-Rob
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org