Re: sourceware.org migration notice

Re: sourceware.org migration notice

[Joseph Myers]

I'd like to check some things regarding the new mailing list archiving 
configuration.

1. Email address munging in list archives messes up more than email 
addresses and ought to be disabled.  E.g. 
http://server2.sourceware.org/pipermail/gdb-patches/2020-February/153667.html 
has Texinfo diffs interpreted as email addresses and munged, which is very 
bad for readability.  (The monthly .txt files have such munging as well.)

2. I'm not sure what the source is from which the mailman version of the 
archives was generated, but it's missing older messages for some lists.  
E.g. the gcc list archives at https://gcc.gnu.org/ml/gcc/ start in 
September 1997, but those at http://server2.sourceware.org/pipermail/gcc/ 
essentially start in November 2001 (the few "earlier" messages are 
actually ones sent later where the sender's clock was way off).  I presume 
the existing /ml/ list archives will remain available in any case, but 
it's clearly best if there's one place someone can look to find all 
messages from the lifetime of a list rather than needing to look in 
different places for older and newer messages.

3. The "Raw text" links in the existing MHonARC archives are a killer 
feature whenever you want to apply a patch from the list archives.  Does 
mailman support such a feature?


I believe the existing MHonARC archiving system is essentially independent 
of qmail / ezmlm - it just involves listarch-* email addresses that are 
subscribed to the lists and pipe each message to 
/sourceware/infra/ml-archiving/www-archives.sh with some options depending 
on the mailing list.  So setting up those addresses to work appropriately 
on the new sourceware and keeping the existing archives updated would 
address all three issues.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sourceware.org migration notice

[Christopher Faylor]

On Thu, Feb 27, 2020 at 02:32:30AM +0000, Joseph Myers wrote:
>I believe the existing MHonARC archiving system is essentially independent 
>of qmail / ezmlm - it just involves listarch-* email addresses that are 
>subscribed to the lists and pipe each message to 
>/sourceware/infra/ml-archiving/www-archives.sh with some options depending 
>on the mailing list.  So setting up those addresses to work appropriately 
>on the new sourceware and keeping the existing archives updated would 
>address all three issues.

We'll be keeping the old mailing list archives around.