[and ... back on list ...]
From: "Rick Moen" rick@linuxmafia.com Date: Thu, 17 Aug 2017 06:07:40 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Rick,
Please feel most graciously invited to, at your convenience (no rush), add yourself as listadmin to BALUG's BALUG-{Announce,Talk} list, if/presuming you still wish to do so.
On the temp.balug.org host, I had already added myself as listadmin to: balug-admin balug-test
I've just added myself to: BALUG-Talk BALUG-Announce
Much thanks! :-)
- How do you feel about lowercasing the real_name and subject_prefix
settings for those? I propose yes.
Since BALUG is acronym, rather than name, I prefer to keep it with uppercase for that portion ... and the portion right after the hyphen (-), and particularly in that context, probably makes reasonable sense / better fit, with an initial cap there ... and so it is, also has been that way a long time.
And yes, certainly debatable ... visibility vs. annoyance, how to (not) handle an acronym, etc.
- Just a note: The merger of the old mbox contents from Dreamhost and
(potentially) other sources of backfill will create a one-time opportunity to select, if we wish, a different archive_volume_frequency setting than Monthly (Archiving Options page). BALUG has always used Monthly, but only because that's the Mailman default rather than as a conscious choice.
For announce and test mailing lists, I recommend Yearly.
For active discussion mailing lists like balug-talk, it's more arguable. Sometimes Quarterly is nice, sometimes Monthly.
balug-admin is sufficiently low-traffic that I suggest Yearly.
Under normal circumstances, there's a strong disincentive against changing, in that you end up assigning new URLs to existing archived postings, which breaks offsite links to the significant ones (if any ;-> ). But if you're merging stuff in, you're going to break most or all of the existing message URLs anyway.
Yes, good considerations. Unfortunately the logic runs contrary to some of the list data. Notably BALUG-Announce and BALUG-Admin (I'll have to review the data again, though, this is off-the-top-of-my-head) have been the least screwed up by DreamHost.com - notably we may have *all* the messages from those lists (or nearly so), and hence it would be good to preserve backwards compatibility on the URLs. I do already have the redirects in place for that - so as long as the sequence numbers line up, the old URLs will redirect to the same messages ... at least after reinjecting those messages, and after lists.balug.org. has been moved over to the new host location.
In the meantime, for temp.balug.org, robots.txt tells the search engines to *not* index the archives (less they get confused as numbers will shift relative to what's presently on temp.balug.org), however messages will be injected before lists.balug.org. is on this host where the active lists are now ... and the robots.txt for lists.balug.org on new host location, very much permits indexing by search engines of all the archives.
And BALUG-Talk is the one DreamHost.com most thoroughly screwed up. Do have much of that (at least in non-ideal form, but at least have it) to be reinjected, and should soon have raw of the more recent of that ... so, since BALUG-Talk is the one where the numbers and alignment of messages are most likely to shift, as I/we work to try and get as much of the missing messages reinjected, that would be top candidate for potentially changing archive frequency. But it's highest volume, so ought probably stay at monthly anyway. And the other lists, lower volume, so by that quarter or yearly would be good, but as those list (at least I think?) are mostly not missing messages, changing that would break all the (individual message) linkage.
So, alas volume vs. archive frequency vs. clean and not-so-clean reinjections and archive fixes to be done, are relatively anti-correlated. :-/
So ... taken all together, I'm relatively inclined to go and remain with monthly.
Now ... BALUG-Test on the other hand :-) - that one is a prime candidate to change. I'd guestimate it's activity will be fairish bursts of activity, but otherwise mostly a lot of nothing or nearly so. So, quarterly, or even yearly, probably makes perfectly fine sense there.
Should decide before lists.balug.org. moves over. But other than that I think either sounds fine for BALUG-Test. What say ye? Preference/recommendation on BALUG-Test? I'm totally open on that one.
And, e.g., on the redirects: Presently have, e.g.: $ curl -I http://lists.balug.org/pipermail/balug-admin-balug.org/2016-April/003013.htm... HTTP/1.1 200 OK Date: Fri, 18 Aug 2017 11:47:02 GMT Server: Apache Last-Modified: Mon, 18 Apr 2016 16:37:20 GMT ETag: "10f5-530c4f972ce72" Accept-Ranges: bytes Content-Length: 4341 Vary: Accept-Encoding Content-Type: text/html
Will later have for lists.balug.org (but already in place on temp.balug.org): $ curl -I https://temp.balug.org/pipermail/balug-admin-balug.org/2016-April/003013.htm... HTTP/1.1 301 Moved Permanently Date: Fri, 18 Aug 2017 11:48:28 GMT Server: Apache/2.4.10 (Debian) Location: https://temp.balug.org/pipermail/balug-admin/2016-April/003013.html Content-Type: text/html; charset=iso-8859-1
There's no there there yet, on the redirect target ... but will be after reinjection of archives, and it will be so on lists.balug.org after that's moved over.
There's somewhat different scheme on the paths for Debian, than is set up on DreamHost.com. I did also note the redirect bits on: https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists (look for the strings redirect and/or rewrite - case insensitive, or much of that is currently close to the bottom of that web page)
And to keep search engines reasonably happy (and optimize some other bits too), generally better to have *one* canonical location for the (same) content, and (permanent, e.g. 301) redirect to that location, rather than have the exact same content at multiple paths and/or hostnames (search engines tend to "dilute" and down-rank such, at least some fair bit, whereas content at one unique location tends to, in general rank better ... various exceptions, but that's at least approximately the general case).