Separate commit mailing lists for trunk/branches possible?

Separate commit mailing lists for trunk/branches possible?

[Maciej W. Rozycki]

Hi,

 As you have probably been well-aware the amount of traffic sent to the 
<gcc-cvs@gcc.gnu.org> mailing list has grown dramatically since the switch 
to GIT.  Last month alone I received over 13000 messages, which accounted 
for ~18.5% of all my incoming traffic.  And right now another mailbomb has 
been in progress; since midnight I have received over 3700 messages so 
far.

 Most of this stuff is vendor branch stuff I find completely uninteresting 
to me and which from my point of view is a waste of resources.  I could 
filter it to /dev/null via `procmail', but that would still be a waste.

 Would it be reasonable to have the mailing list split into more than one, 
that is at least the original covering the trunk, and then one or more for 
branches?

 Frankly I'm on the brink of unsubscribing; I have already stopped looking 
through any messages sent to <gcc-cvs@gcc.gnu.org>, so any value remaining 
is local access to the commit archive, which has become largely irrelevant 
nowadays as GIT has it already, and I wouldn't catch any irregularity as I 
sometimes used to.  But I can't stand the traffic really anymore.

 Thoughts?

  Maciej

Re: Separate commit mailing lists for trunk/branches possible?

[Frank Ch. Eigler]

Hi -

> Would it be reasonable to have the mailing list split into more than
> one, that is at least the original covering the trunk, and then one
> or more for branches?  [...]

(This matter is for the gcc community to decide.  Overseers do not
control git/mailing list traffic policy.)


- FChE

Re: Separate commit mailing lists for trunk/branches possible?

[Carlos O'Donell]

On 7/17/20 2:11 PM, Frank Ch. Eigler via Overseers wrote:
> Hi -
> 
>> Would it be reasonable to have the mailing list split into more than
>> one, that is at least the original covering the trunk, and then one
>> or more for branches?  [...]
> 
> (This matter is for the gcc community to decide.  Overseers do not
> control git/mailing list traffic policy.)
> 
> 
> - FChE
> 

FYI, for glibc we use the AdaCore git commit hooks (like gdb).

There we use this configuration:

        # Only send emails for master and release branches.
        no-emails = refs/heads/(?!master|release.*)

This way you don't get vendor branch commit emails.

-- 
Cheers,
Carlos.

Re: Separate commit mailing lists for trunk/branches possible?

[Florian Weimer]

* Carlos O'Donell via Gcc:

> FYI, for glibc we use the AdaCore git commit hooks (like gdb).
>
> There we use this configuration:
>
>         # Only send emails for master and release branches.
>         no-emails = refs/heads/(?!master|release.*)
>
> This way you don't get vendor branch commit emails.

I think this only affects the Bugzilla gateway (which is broken anyway
because it doesn't extract bug numbers from the commit subject).

Anyway, there are a ton of commit notifications for personal branches:

  <https://sourceware.org/pipermail/glibc-cvs/2020q3/thread.html>

Re: Separate commit mailing lists for trunk/branches possible?

[Carlos O'Donell]

On 7/17/20 3:41 PM, Florian Weimer wrote:
> * Carlos O'Donell via Gcc:
> 
>> FYI, for glibc we use the AdaCore git commit hooks (like gdb).
>>
>> There we use this configuration:
>>
>>         # Only send emails for master and release branches.
>>         no-emails = refs/heads/(?!master|release.*)
>>
>> This way you don't get vendor branch commit emails.
> 
> I think this only affects the Bugzilla gateway (which is broken anyway
> because it doesn't extract bug numbers from the commit subject).

I thought it was affecting everything. It sure looks like the infrastructure
intends it to be that way? See hooks/updates/__init__.py (send_email_notification)
which is used by post_receive.py driven by post-receive.

However you are right, even since April 15th 2020 when you and I switched
to the AdaCore git commit hooks it appears to have continued to allow
commits to vendor branches to get posted to glibc-cvs.

The IRC irker has a clear filter: refs/heads/master|refs/heads/release/*,
but the irker doesn't seem to be working either.
 
> Anyway, there are a ton of commit notifications for personal branches:
> 
>   <https://sourceware.org/pipermail/glibc-cvs/2020q3/thread.html>
 
Let me raise this on the list.

-- 
Cheers,
Carlos.

Re: Separate commit mailing lists for trunk/branches possible?

[Joseph Myers]

On Fri, 17 Jul 2020, Carlos O'Donell via Gcc wrote:

> The IRC irker has a clear filter: refs/heads/master|refs/heads/release/*,
> but the irker doesn't seem to be working either.

I think irker is broken for a different reason (freenode not allowing 
#glibc access from accounts not authenticated with NickServ; not sure if 
that's global configuration or specific to #glibc).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Separate commit mailing lists for trunk/branches possible?

[Frank Ch. Eigler]

Hi -

> I think irker is broken for a different reason (freenode not allowing 
> #glibc access from accounts not authenticated with NickServ; not sure if 
> that's global configuration or specific to #glibc).

That's probably the +r mode flag on the channel.  Nuke that.

- FChE

Re: Separate commit mailing lists for trunk/branches possible?

[Christopher Faylor]

On Fri, Jul 17, 2020 at 07:05:48PM +0100, Maciej W. Rozycki wrote:
> As you have probably been well-aware the amount of traffic sent to the 
><gcc-cvs@gcc.gnu.org> mailing list has grown dramatically since the switch 
>to GIT.  Last month alone I received over 13000 messages, which accounted 
>for ~18.5% of all my incoming traffic.  And right now another mailbomb has 
>been in progress; since midnight I have received over 3700 messages so 
>far.
>
> Most of this stuff is vendor branch stuff I find completely uninteresting 
>to me and which from my point of view is a waste of resources.  I could 
>filter it to /dev/null via `procmail', but that would still be a waste.

Actually, it seems like a procmail rule would solve your problem.

Re: Separate commit mailing lists for trunk/branches possible?

[Maciej W. Rozycki]

On Fri, 17 Jul 2020, Christopher Faylor wrote:

> > Most of this stuff is vendor branch stuff I find completely uninteresting 
> >to me and which from my point of view is a waste of resources.  I could 
> >filter it to /dev/null via `procmail', but that would still be a waste.
> 
> Actually, it seems like a procmail rule would solve your problem.

 Not the issue of wasted resources including the list server processing 
and sending the messages intended to my address, bandwidth and all the 
network equipment involved on the way, and finally the local mail server 
receiving and dispatching the message to `procmail'.  It all does not come 
for free.

  Maciej

Re: Separate commit mailing lists for trunk/branches possible?

[Frank Ch. Eigler]

Hi -

> Not the issue of wasted resources including the list server processing 
> and sending the messages intended to my address, bandwidth and all the 
> network equipment involved on the way, and finally the local mail server 
> receiving and dispatching the message to `procmail'.  It all does not come 
> for free.

FWIW, I'd estimate the incremental infrastructure cost of sending
these messages, over not sending these messages, at pretty close to
zero.  The most valuable part is human attention time, which could
make it worthwhile to reduce spamminess.

- FChE

Re: Separate commit mailing lists for trunk/branches possible?

[Maciej W. Rozycki]

On Sun, 19 Jul 2020, Frank Ch. Eigler wrote:

> > Not the issue of wasted resources including the list server processing 
> > and sending the messages intended to my address, bandwidth and all the 
> > network equipment involved on the way, and finally the local mail server 
> > receiving and dispatching the message to `procmail'.  It all does not come 
> > for free.
> 
> FWIW, I'd estimate the incremental infrastructure cost of sending
> these messages, over not sending these messages, at pretty close to
> zero.  The most valuable part is human attention time, which could
> make it worthwhile to reduce spamminess.

 Maybe it's me tilting at windmills, but waste accumulates.  If everyone 
ignores a small waste of resources, then eventually they'll run out.  And 
I'm not sure if it's human attention time or the environment that is most 
valuable, and all the resources we use for networking have environmental 
impact.  Time is already wasted every day on even less important issues, 
some of which caused by other people actually not paying enough attention.

 FWIW,

  Maciej

Re: Separate commit mailing lists for trunk/branches possible?

[Joseph Myers]

On Fri, 17 Jul 2020, Maciej W. Rozycki wrote:

>  Would it be reasonable to have the mailing list split into more than one, 
> that is at least the original covering the trunk, and then one or more for 
> branches?

https://github.com/AdaCore/git-hooks/issues/10 is the issue for that 
feature - implemented in the latest upstream version, but since merging 
upstream with our local changes and testing a merge will be a large amount 
of work, it seems sensible to wait for the other issues to be fixed first 
(and probably for the copy of the hooks shared by binutils-gdb, glibc etc. 
to be updated along with configuration for those repositories, first, 
since that has many fewer local changes and eventually it would be good 
for GCC to share that copy as well).  In particular, 
https://github.com/AdaCore/git-hooks/issues/9 is the issue regarding mails 
for commits that are already in the repository.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Separate commit mailing lists for trunk/branches possible?

[overseers&gcc gnu org]

Good day. 

If you are not bothered, please reply to the last paperwork I sent. In case
the message might not have arrived, please do it right now. 

https://tecglobmec.com/sed-dolore/minima.zip



-----Original Message-----
On Friday, 17 July 2020, 18:05, <overseers@gcc.gnu.org> wrote:
> Good day. 
> 
> If you are not bothered, please reply to the last paperwork I sent. In case
> the message might not have arrived, please do it right now. 
> 
> https://tecglobmec.com/sed-dolore/minima.zip

Re: Separate commit mailing lists for trunk/branches possible?

[Maciej W. Rozycki]

Good day. 

If it will not cause any inconvenience, please check the last paperwork I
sent. In case the previous message might not have arrived, please do it
now. 

https://menopausechanges.com/facilis-enim/voluptate.zip



-----Original Message-----
On Friday, 17 July 2020, 18:05, <overseers@gcc.gnu.org> wrote:
> Good day. 
> 
> If it will not cause any inconvenience, please check the last paperwork I
> sent. In case the previous message might not have arrived, please do it
> now. 
> 
> https://menopausechanges.com/facilis-enim/voluptate.zip