[kernel.org users] LKML on patchwork.kernel.org

[Theodore Ts'o]

On Tue, Jul 15, 2014 at 08:57:32PM -0400, Steven Rostedt wrote:
>>I mostly ask because every now and again patchwork likes to eat 8GB of
>>RAM (and would probably eat more if allowed), and I suspect it's when
>>it's trying to parse or display some of the longer-running threads.
>
> ....
>
> Actually, I would really like it if kernel.org did its own archiving of
> LKML. I hate that the http://lkml.kernel.org/r/<messageid> goes to
> marc.info, as we have seen in the past, that's not always operational.

+1.

I wonder if there's some way kernel.org could partner with one of the
existing mailing list archives so we could have a reliable LKML mail
archive with stable URL's that can be addressed via message-id.
Preferably one that had multiple UI views of the messages, such as
gmane's blog, article, thread, etc., views.

If we had that, then one thing you could to ease the workload on
patchwork.kernel.org by not trying to store, parse, or display the
message threads inside patchwork.  Instead, patchwork could just store
and display a link to the message thread stored in a purpose-built
mail archiving system, which might be part of the kernel.org services,
or separately -- but the important bit is that it could be run on a
separate server from patchwork.kernel.org.  (Or maybe the link could
be shown in an iframe, and if the mail archive system had an option
which displayed all of the followups in a single web page, then it
would work exactly as what we have today.)


The other thing we could do (and that's why I've cc'ed
patchwork at lists.ozlabs.org, since this is more of patchwork feature
request) is it would be nice if patchwork had a new feature where it
displayed "related patches" that were on the same message thread
(based on message id's) or by elimiating things like "PATCH", "-v2",
"-v3", etc and doing a similarity analysis on the subject line, and
then displayed the link to the patch on the patchwork server, the
related patch'es status (i.e., superceeded, not applicable, etc.) and
the subject line of the patch.

That would make it much easier for people browsing the LKML patchwork
pages to find other patches in a patch series, and to figure out if
there is a newer version of the patch (since they can't depend on the
patch status being accurate, because it's not practical to give a
large number of kernel developers access so they can curate the
patches for the LKML patchwork project).

Cheers,

						- Ted