Mail slowness part MXCIV

Mail slowness part MXCIV

[Lars Magne Ingebrigtsen]

One of the nice things about having commit messages and diffs go to a
mailing list is that you can keep track, easily, of what people (and
yourself) are doing.  Reading the commit messages is much more handy
than trying to see what people did via the vc.

Which is why it's so frustrating that the GNU mailing lists are so slow,
and are so erratic.

At the time of writing this, the last commit mail was posted 46 hours
ago.  Have there been oodles of commits in the mean time?  Yes.

If, as usual, it turns out that it's impossible to get anybody to
actually do something about the apparent main problem (erratic mailing
list MTAs), could we just add the Gmane submission email address as a Cc
to the commit messages, so that it would be possible to read the
messages anyway?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Mail slowness part MXCIV

[Leo]

On 2011-07-18 00:04 +0800, Lars Magne Ingebrigtsen wrote:
> If, as usual, it turns out that it's impossible to get anybody to
> actually do something about the apparent main problem (erratic mailing
> list MTAs), could we just add the Gmane submission email address as a Cc
> to the commit messages, so that it would be possible to read the
> messages anyway?

That would be great!

Leo

Re: Mail slowness part MXCIV

[Leo]

On 2011-07-18 00:04 +0800, Lars Magne Ingebrigtsen wrote:
> If, as usual, it turns out that it's impossible to get anybody to
> actually do something about the apparent main problem (erratic mailing
> list MTAs), could we just add the Gmane submission email address as a Cc
> to the commit messages, so that it would be possible to read the
> messages anyway?

That would be great!

Leo

Re: Mail slowness part MXCIV

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> list MTAs), could we just add the Gmane submission email address as a Cc
> to the commit messages, so that it would be possible to read the
> messages anyway?

That doesn't help if the problem is with sending mail on Savannah.

Try opening a Savannah support request in the first instance.
It certainly looks like something has gone wrong at the moment.

If the problem is a general GNU mailing list one, then try asking
sysadmin@gnu.

Nobody at emacs-devel can really do anything about this directly.

Re: Mail slowness part MXCIV

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Try opening a Savannah support request in the first instance.
> It certainly looks like something has gone wrong at the moment.

It's always like this, as far as I can tell.  Commit messages appear two
to fifty two hours after the commit has been done.

The mailing lists are typically ten minutes to nine hours, so they're
usually a bit faster.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Mail slowness part MXCIV

[Glenn Morris]

Glenn Morris wrote:

> That doesn't help if the problem is with sending mail on Savannah.

Given that my mail to this list arrived in about 2 minutes, it obviously
is, so I filed

https://savannah.gnu.org/support/index.php?107743

In general, emacs-devel is the wrong place to ask about GNU
infrastructure.

Re: Mail slowness part MXCIV

[Stefan Monnier]

>> Try opening a Savannah support request in the first instance.
>> It certainly looks like something has gone wrong at the moment.
> It's always like this, as far as I can tell.  Commit messages appear two
> to fifty two hours after the commit has been done.

IIUC part of the problem is that the Bzr commit emails are generated via
polling: basically like repeatedly doing a "bzr pull" until you see that
there's something new at which point you send the content that you
just pulled.


        Stefa

Re: Mail slowness part MXCIV

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IIUC part of the problem is that the Bzr commit emails are generated via
> polling: basically like repeatedly doing a "bzr pull" until you see that
> there's something new at which point you send the content that you
> just pulled.

That part is working fine, as you can see from last_revision_mailed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mail slowness part MXCIV

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IIUC part of the problem is that the Bzr commit emails are generated via
> polling: basically like repeatedly doing a "bzr pull" until you see that
> there's something new at which point you send the content that you
> just pulled.

Using a post-commit hook would surely be faster, more reliable and use
fewer resources?

I googled, and apparently bzr supports doing this:

http://doc.bazaar.canonical.com/plugins/en/email-plugin.html

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Mail slowness part MXCIV

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Using a post-commit hook would surely be faster, more reliable and use
> fewer resources?
>
> I googled, and apparently bzr supports doing this:
>
> http://doc.bazaar.canonical.com/plugins/en/email-plugin.html

I think Savannah disabled bzr plugins due to security concerns.
I think this is covered somewhere in the Savannah mailing list archives.