On 2/29/20 9:02 AM, Stephen J. Turnbull wrote:
Alan Kelm writes:
Since 2005, our organization has been running a customized version of Mailman 2 with extensions that meet our particular needs. The main novelty is support for /fixed subscription lists/, in which the list members are predetermined (corresponding to a "committee").
It's not clear to me that this can't be achieved with existing Mailman 2 (or 3) features. That is, a committee's list could be populated using mass subscribe, and unsubscriptions can be prevented by requiring admin intervention.
You are correct in pointing out that fixed lists could be implemented without customizations to Mailman, provided that one is willing to leave intact various references to users subscribing and unsubscribing themselves. Modifications were required in 6 separate places (for Mailman 2) to suppress such references for fixed lists. We had additional extensions to permit programmatic re-syncing of subscriber and permitted sender lists with data sources, an adjustment to suppress monthly subscription reminders for such lists, and lots of other minor tweaks that were not strictly necessary.
I'm not sure why this (or the "hybrid" list) requires patches. If I am correct that the basic functionality is present, and requires only small tweaks, it might be possible to include those tweaks in Mailman 3 itself. (I can't promise; this requirement also seems quite rare, and if substantial code changes, or multiple configuration options, were required, we might prefer to avoid them.)
Our hybrid lists were implemented using separate lists - an outer /opt-in/ list having a /fixed/ list as one of its subscribers (using a generic parent/child list framework). Quite a few customizations were needed to smooth over the rough points of this arrangement (for example to ensure that only the parent list's subject line prefix appears on message subject lines). Now that I reflect upon it, it would be likely be possible to maintain a mandated list of subscribers as a subset within an opt-in list (provided that one keeps a separate copy of the mandated subscribers, to enable detection of previously mandated addresses that need to be deleted).
If I were to implement hybrid lists under Mailman 3, I would be inclined to look for simpler mechanisms that what we used under Mailman 2.
We are considering moving to Mailman 3 and would like to do this in a way which makes it possible to periodically upgrade our installation to the newest Mailman version, without clobbering our customizations. Thus, I do not think that installing via "pip" is the right approach for us. While I'm relatively new to git and GitLab, they seem to be ideally suited to this situation. If I understand the developer documentation correctly, I start out by creating a "fork" and can later "fetch" changes from the master branch and "rebase" to bring them into our branch.
Your understanding is correct in principle. If you don't have experienced git users around, you might want to find somebody to help you design a workflow. Eg, in general you want to rebase your changes on top of the mainline, rather than the other way around. You also need to be prepared for occasional cases where your patch conflicts with something we do in the same place of the same file.
Thank you for these helpful comments. When the time comes, we'll make sure to get the git configuration worked out properly.
My investigations over the past few days have convinced me that we are better off sticking with Mailman 2 for a while longer. One feature which is essential for us is to have the list manager informed of bounces, so that failing addresses can be corrected and important missed messages can be resent by other means. The lack of bounce handling in Mailman 3.2 is therefore a showstopper for us. (One of our customizations for Mailman 2 ensures that bounce notifications are sent to the list manager, but this was just a small tweak to existing bounce handling code).
I look forward to returning to take another look at Mailman 3 in the future. Thank you, once again, for your helpful comments.
-Alan
-- Alan Kelm Manager, Electronic Services Canadian Mathematical Society