On Fri, Oct 25, 2019 at 07:50:22AM -0700, Alexei Starovoitov wrote:
The last few days I've experienced long email delivery when I was not
directly cc-ed on patches.
Even right now I see some patches in patchworks, but not in my inbox.
Few folks reported similar issues.
In order for everyone to review the submissions appropriately
I'll be applying only the most obvious patches and
will let others sit in the patchworks a bit longer than usual.
Sorry about that.
Ironic that I'm using email to talk about email delays.
My understanding that these delays are not vger's fault.
If you're receiving them at your gmail address, then it's possible
Google is throttling how much mail it allows from vger.kernel.org. At
least, that's the usual culprit in my experience (I don't have access to
vger, so I can't check this assumption).
Some remediations may be used sporadically, but
we need to accelerate our search of long term solutions.
I think Daniel's l2md:
https://git.kernel.org/pub/scm/linux/kernel/git/dborkman/l2md.git/
is a great solution.
It's on my todo list to give it a try,
but I'm not sure how practical for every patch reviewer on this list
to switch to that model.
Remember that all lore.kernel.org lists are also available via NNTP,
e.g.:
nntp://nntp.lore.kernel.org/org.kernel.vger.bpf
I know some people can't use it easily due to NNTP ports being blocked
on their corporate networks, but it's another option to receive list
mail without waiting for SMTP to unclog itself.
Thoughts?
One service I hope to start providing soon is individual public-inbox
feeds for developers -- both for receiving and for sending. It would
work something like this:
- email sent to username@xxxxxxxxxx is (optionally) automatically added
to that developer's individual public-inbox repository, in addition to
being forwarded
- that repository is made available via gitolite.kernel.org (with read
permissions restricted to just that developer)
- the developer can pull this repository with l2md alongside any
list-specific feeds
- the hope is that the future tool we develop would allow integrating
these multiple feeds into unified maintainer workflow, as well as
provide the developer's individual "outbox.git" repository
There are some things that still need to be figured out, such as obvious
privacy considerations (public-inbox repositories can be edited to
remove messages, but this requires proper hooks on the server-side after
receiving a push in order to reindex things). It's one of the topics I
hope to discuss next week.
-K
