On 2/26/21 10:00 PM, Stephen J. Turnbull wrote:
Thank you for going to the trouble of making your guide easily available to and usable by the community.
You're welcome Steve.
Yes, and we try to document them all, written by different people at different times. I don't think that's an unreasonable approach given the wide variety of situations of our site admins, but I'm sure a lot of "greenfield" installations will appreciate your thorough, "from parts manifest to assembled working system", approach.
I agree. I just know there are probably a lot of folks who just want a working and current Mailman 3 server and are not picky over the actual server environment. Mailman 3 is really dependent upon being connected to a number of services: web server, database server and MTA for instance. Then you add in all of the required Python modules, and you have a really complicated system that has a lot of moving parts.
I intend to explore other OS for installing MM3 and to document that process as well. I will not document the process of using package managers (apt/yum) etc to install Mailman 3 itself because I think it is very problematic having older versions of Mailman 3 set up. Mark Sapiro put it very well when he said:
Mailman 3 is still relatively young and there are many important features and fixes in the current releases that aren't in the Debian/Ubuntu packages.
I hoping a guide such as mine will move folks away from using a Debian repo for Mailman installations.
Yes, it has been a problem. At this point I'm pretty sure :^รพ that mailman.readthedocs.io is the official guide, but that hasn't been well-known in the past and there are a lot of mirrors and unofficial guides like yours (but not as thorough). And there's a lot of stuff on the Wiki that requires effort to integrate because it was originally written in reply to a particular user's questions.
See that is something I am very interested in fixing and cleaning up but I need help in knowing how to work with something like Readthedocs.io.
Sphinx is pretty much the gold standard for Python documentation. It looks nice. The markup is reStructuredText, which is a powerful, Markup-like language with a few features that Markup didn't have last I looked, and it's extensible by Python programmers. It's also used in marking up Python docstrings. So you can see why we'd choose it. But if you're *not* an experienced Python programmer, none of those are advantages.
Exactly!
I am just trying to understand how can we lower the barrier for community members to help contribute to existing docs instead of them having to create new ones. Specifically around installation, since that tends to get stale often when depedent packages change or a new dependency is added that breaks the installation.
@Abhilash: For non-Python programmers, it's not *that* hard, but there is a hurdle at the beginning.
So lift me up and throw me over that hurdle.
I think the best thing to do is to advertise that we're always looking for doc contributions, and that if somebody's not familiar with reST, they shouldn't let that stop them. Of course we'll help them with markup, and if necessary we'll do it.
"Raises hand here"
-- Brian Carpenter Harmonylists.com Emwd.com