[BALUG-Admin] list settings? ...

[Michael Paoli]

[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!  :-)

> 1.  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.

> 2.  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.html
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.html
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).