Hi,
>> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html >> Looking around, the last two months of gcc now have very small >> numbers, but e.g. on gcc-patches the mails have very high numbers like >> 545238.html. Can pipermail provide stable URLs at all? We really >> need those, we reference those in commit messages, other mails, bugzilla >> etc. > > Argh, that is a problem, sorry. We get mailman to regenerate web > archives for example in the case of spam that has gone through. Our > recipe has been to delete the spam from the apropriate .mbox, but this > does renumber things. > > The big vs. little numbers are probably an accidental function of > whether the email .mbox files were processed chronologically or not. > I'll tweak the mrefresh script to make sure it's chronological; that > should avoid gross jumps like that. I believe gcc-patches just wasn't > regenerated for spam removal whereas others have. There should not be > gross jumps in the future, except we'll have to regenerate everything > one more time. :-( > > Small jumps though --- darn, we'd have to do something else with spam > in the mbox, maybe replace it somehow in situ with something else. Or > catch it so quickly that subsequent URLs aren't archived anywhere > important. > > It would be good to have another way of making permanent URLs for > individual messages in mailing list archives. may I also chime in with a related (to some extent), even though a separate issue? It seems URL rewriting rules designed to replace old-style https://gcc.gnu.org/ml/<list name>/current URLs pointing to monthly digests to current ones https://gcc.gnu.org/pipermail/<list name>/<year-month>/date.html#end broke with onset of May. I mean, if I type https://gcc.gnu.org/ml/gcc/current I still get https://gcc.gnu.org/pipermail/gcc/2020-April/date.html#end (note 2020-April) instead.
