patch review delays

patch review delays

[Alexei Starovoitov]

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.
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.
Thoughts?

Re: patch review delays

[Konstantin Ryabitsev]

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

Re: patch review delays

[Eric Wong]

Alexei Starovoitov <alexei.starovoitov@gmail.com> 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.
> 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.
> Thoughts?

If cloning git repos is too much work, You can subscribe to an
Atom feed of search results to paths or files you're interested
in using "dfn:" (diff-file-name) using your favorite feed
reader:

lore.kernel.org/lkml/?q=dfn:path/to/dir-or-file-youre-interested-in&x=A

Or drop the "&x=A" to get an HTML summary, or POST to that URL
with "&x=m" to download an mbox.

You can also search for multiple files at once by having dfn:foo
multiple times separated by "OR"

lore.kernel.org/lkml/?q=dfn:foo+OR+dfn:bar&x=A

https://lore.kernel.org/lkml/_/text/help/ has other prefixes
like "dfn:" which might be helpful for search.

For example, if you expected to be Cc-ed (or To-ed) and want to
double-check that your mail account got it, you can use the "c:"
or "tc:" prefixes with your name or address, too.

Re: patch review delays

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> https://lore.kernel.org/lkml/_/text/help/ has other prefixes
> like "dfn:" which might be helpful for search.

Btw, I'm hoping to expand that search functionality to be
available for both local/private mail and git code repos
while being network-transparent and capable of handling
multiple accounts.

mairix and notmuch both hit scaling problems for my personal
mail; so I'll be needing on something that can replace them.