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.
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.) It's certainly good you posted here, and might be a good idea to post to the Mailman 2 users' list, to get others' opinions on your changes.
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.
Steve