Re: Stability of pipermail ml archive URLs

[Christopher Faylor <cgf-use-the-mailinglist-please@gcc.gnu.org>]

On Thu, May 07, 2020 at 01:56:04PM -0400, Frank Ch. Eigler wrote:
>>>I was thinking we might be able to trick pipermail (the web archiver
>>>component) to simply name the message web urls after some function of
>>>the message-id instead of the sequence number.  Will give this a try
>>>very shortly.
>>
>>I just want to go on record as saying that I think this is a bad idea.
>>We can fix this problem simply without redesigning pipermail.
>
>If the idea requires more than a dozenish lines of code, then I agree
>it's not worth doing.  "redesigning" - indeed no thanks.

I'd call a major change to the way that mailman archives files a
"redesign".

>>The problem that we're seeing is caused by a script that I wrote to
>>migrate ezmlm to mailman.  The fix for the problem is "Don't run that
>>script".
>
>Yeah, but that is the official mailman2 method for this.

One recommended method is to edit the mbox file and leave the message
around but blank and then regenerate the archive.  But, that could cause
renumbering issues.

They also mention what I'm suggesting - edit the mbox and html files and
leave the content blank.  You'd have to be careful not to step on incoming
email in that scenario, of course.

https://wiki.list.org/DOC/How%20can%20I%20remove%20a%20post%20from%20the%20list%20archive%20or%20remove%20an%20entire%20archive%3F

The above mentions that the message would be in three places which are
easily editable.  There is also prev and next links which apparently
live in a database but there are scripts available to fix that too.

Spam used to be in multiple places when we were running ezmlm.  It never
occurred to me that we needed to modify ezmlm to deal with the issue.  I
used to get rid of viruses using a "mlzap" script that hit the right
files.  That technique should work here too.

OTOH, maybe we should just give up on mailman2 and move to something
more modern even if we can't use dnf to install it on RHEL.  I'm surely
not a fan of mailman2.  If we have to do head-standing to get it to work
the way we want then maybe we should just move on and forget that we
said we wanted to use something "stable".