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 [email protected], 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 _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
