Re: patch review delays

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

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@kernel.org 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