On 2/25/21 8:28 PM, Abhilash Raj wrote:

Thanks Brian, this looks quite comprehensive in the details. The only thing I am a bit concerned about is granting sudo privileges to the Mailman user. It really shouldn't have sudo given that Mailman and Django are supposed to run as mailman user. Any compromise of the Django application will provide the attacker root on the machine.

Thanks for pointing that out. I have removed that step. It really wasn't needed.

Is there a specific reason that you chose to go with an entirely new doc

Yes. Just from observing the communications on this list, there are multiple ways to install Mailman 3 which produces installation issues, database problems, outdated apps, etc. My document produces a VERY stable installation of Mailman 3 and one that is easy to maintain and update. It is also very comprehensive covering not just Mailman Suite, but the configuration of an entire server environment. Personally I think the choice of Debian, NGINX, Postfix, and PostgreSQL makes for a long and loving relationship with Mailman 3 but I do understand everyone has their own environment that they want to work with. My guide represents a very stable and easily maintained environment for me and hopefully others.

rather than helping to improve the existing one? Several parts of it (at least the ones that official guide covers) seems similar to me and is duplicate information that at least two people are going to spend time writing and maintaining in future.

Is there an official guide? See that is the problem. I did not know there was an official guide. Because every time I tried finding documentation in the past using Google searches, I got fed outdated information. So for me the guide that I came up with, works great for me and if no one else uses it, I certainly will.

Your guide, by nature has to be minimalistic to accommodate all the various server environments out there. My is meant to be narrow but comprehensive.

Is it something about the contribution process to the official documentation that makes it hard for people to contribute? Most of the pages at docs.mailman3.org or come from this[1] repo and use Sphinx to build and REsT formatting (.rst).

[1]:https://gitlab.com/mailman/mailman-suite-doc

Well I don't know much about any of the above approach to documentation. So I would say that is a hindrance.

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.

I had to update my guide twice due to recent changes made to the installation process such as the addition of the Dart Sass section and the problem with the cryptography module when installing Hyperkitty. While my guide covers these new hurdles to a new installation, I don't think yours says anything about them. The Dart Sass section came from Mark's comments on this list.

-- Brian Carpenter Harmonylists.com Emwd.com

On 2/25/21 10:35 PM, Abhilash Raj wrote:

I think it is okay to be pick up a specific configuration and provide a guide to installation keeping that as the target technology. As it happens to be, the official doc uses the same set, Nginx, Postfix and PostgSQL.

https://docs.mailman3.org/en/latest/install/virtualenv.html

Thank you for pointing the above out. I will keep track of the URLs you provided in this thread and I am willing to also assist to try to make sure such links are propagated via search engine results.

I don't see anything very specific to Debian in the doc except the package names and I think they are similar enough in Debian derivative distros that we can write up that assumption up front in the top.

Given that most of the installation is based off on pip, I don't think there is going to be a *lot* of deviation for even RHEL/Fedora based distros when it comes to Mailman itself. Some minute deviations could occur with the behavior of certain commands, like nano doesn't exist, but I still expect 95% of the doc to be the same, except obviously the package names.

I agree. One of my goals was to make it easy for Mailman 3 adopters to use a different installation method other than a repo since distro packages tend to install older versions of Mailman 3 core, Postorius, and Hyperkitty. At this stage of Mailman 3 development, these new versions bring a LOT of improvements to the Mailman 3 user.

I am also willing to start testing out my installation method on other distros and document the differences. If you are willing to help me, I have no problem posting installation instructions and tips to Mailman 3's official documentation. I am also more than willing to keep such documentation up to date. I am always being called upon to install Mailman 3 for someone, so I seem to be on the front-line when it comes to "surprises" such as the issue with the cryptography module. That puts me in a good position to update documentation simply because I need to know such things for the next install.

I am not that well versed in SEO, but the official website https://list.org does point to it. Maybe not prominently enough for new users to discover? I'll see if we can make the discovery of docs.mailman3.org better.

I think the issue I found was running into outdated documentation for older versions of Mailman 3. Even doing a search for an up to date changelog or release notes are problematic. Again, I am also willing to help out with trying to get such vital pieces of information showing up prominently in search results.

I guess it is fine to be opinionated about choosing the technologies but yet provide pointers to help people using other technologies.

Right now, I do that using "Hints" and "Notes" and "See also" banners through out the documentation to point to different pages where they can lookup setup for other technologies. For example, how to setup MySQL if official doc recommends Postgres.

Are there still any outstanding issues with using MySQL? I know I ran into some when I tried to use MySQL and chose to go with PostgreSQL (which I am so glad I did). I still recall even seeing some recent issues brought to this list for someone using MySQL. I know MySQL is very popular for websites so I do believe the momentum for someone to set up a Mailman 3 server is to go with MySQL. Perhaps just putting up some heads up warnings (here there be dragons!) IF there are still issues out in the wild for those wanting to use MySQL with Mailman 3. Personally I will always steer clients to PostgreSQL when I get a chance. My own documentation reflects that bias.

Gitlab has a fairly good experience editing REsT files and you don't necessarily have to do much outside of a Web Browser actually. It lets you preview before saving like wiki.list.org and you can submit it for review and merging into main repo.

Would you be more willing to contribute to official documentation if we documented the Gitlab contribution process better?

Absolutely. My current installation documentation was the result of a certain beautiful Mailman developer who I won't name (just protecting your privacy Mark!) providing me assistance when I decided to go with the certain installation direction. So if you scratch my back (i.e. teach me Master for I am your student!) then I will scratch yours.

Because we haven't yet gotten to updating those in the official docs, unfortunately. And there are more things missing like Fulltext search (Xapian recommended) and more of the Email setup like SPF and DKIM. Very much aligned with your plans, which is why I suggested contributing updates to docs.mailman3.org instead :)

Well show me how to update the documentation and I will certainly take care of those things. I am also now comfortable in getting OpenDKIM working with Mailman 3 so I can also provide documentation there as well. I have done Xapian installations for clients but unfortunately did not document my methods so I will need to work on that. How do you feel about documentation for the use of Elasticsearch and Solr?

Remember, I was a Mailman 2 host for years using cPanel. cPanel took the thinking of out a lot of things when it came to Mailman 2 hosting and I don't have that crutch anymore with Mailman 3.

-- Brian Carpenter Harmonylists.com Emwd.com

On 2/27/21 4:36 AM, Stephen J. Turnbull wrote:

As far as I know the "emoji" problem (MySQL doesn't handle Unicode characters outside of the Basic Multilingual Plane by default) is still present. Given that emoji are now in use by pretty much everybody and easily accessible on most platforms, this default is unfortunate. However, I believe this is a server-wide setting, so I am dubious that Mailman should force the "full Unicode" setting on. (Anybody who knows feel free to correct me.)

As far as I know, the OPTIONS {'charset': 'utf8mb4} setting in the DATABASES definition for mysql (see <https://gitlab.com/mailman/mailman-suite/-/blob/master/mailman-suite_project/settings.py#L142>) will fix this issue.

Although, one user may be currently having this issue where the OPTIONS setting doesn't fix it <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/6TWVUPBUEMYNZCZDSVW727XBJVDNM4YI/>

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/27/21 3:48 PM, Ruth Ivimey-Cook wrote:

It is also possible to Alter existing databases and tables, but with one catch: the maximum table row length is reduced, so some tables will need to be adjusted (e.g. converting varchar(255) to varchar(230)).

This is misleading. The maximum row length depends on the actual data stored in the row. The sum of the various column size limits for VARCHAR and other columns can well exceed the maximum row size as long as the sum of the lengths of the actual data stored in the row does not.

The significant issue is all these limits are bytes, not characters, so in the worst case, a VARCHAR(255) column can only store 85 3-byte utf8 encoded unicodes or 63 4-byte utf8mb4 encoded unicodes, but this too is misleading an most strings contain single byte encodings with some 2 or 3 byte encodings and maybe at most one or two 4-byte encodings.

Furthermore, the problem issues are essentially limited to emojis and possibly other 4-byte encoded symbols in email subject headers and bodies. Bodies are a TEXT field and the data are stored separately and do not affect the row size and subjects are defined with a maximum length of 512 bytes which should be sufficient.

None of the data stored in rows is at all likely to exceed the maximum row length, even with a lot of 4-byte encodings.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

• Johannes Rohr (johannes@rohr.org) [210314 18:30]:

Please excuse me, if this has been discussed before and I missed it, but what is the added value of going through the trouble of manually installing mailman3, rather than doing a simple apt install mailman3-full? I would assume that in most cases, a well maintained package is preferable, because it makes life easier. Are the Debian packages for Mailman3 in some way deficient?

As always, packages in Debian stable are not as new as the latest git checkout.

So, if the stable version work for you: great.

If you want to have something newer, either try the packages from testing / unstable, or some checkout from git. If you want to improve the code, git checkouts are of course also preferred.

Of course, this is true not only for mailman3, but also for exim, kde, gimp, whatever.

Andi

Andreas Barth writes:

Of course, [git main always has features, sometimes lots of them, not in the distro packages] is true not only for mailman3, but also for exim, kde, gimp, whatever.

Well, this is more true of Mailman than those other packages for a few reasons. As Mark points out, Mailman is evolving, but I wouldn't say more rapidly than those other examples. However, one important driver of Mailman 3 evolution is that the Internet is a hostile environment, and many changes in Mailman are driven as a response to security or other issues that are out of your control as admin of an Internet host.

It's true that distros are pretty responsive to that kind of issue, and frequently backport security patches to the version they support quickly, but heavily patched versions have their issues, too.

In general I would say that distro packages are extremely well-suited to establishing a stable baseline for your host (and for Debian, at least, you can flexibly choose how stable various parts are), but for mission-critical applications you shouldn't *default* to the distro package. You should carefully evaluate whether the distro version historically has kept pace with upstream, whether it is featureful enough, and whether it's worth your time to do work that will eventually be done by the distro's package maintainer (you hope ;-).

Brian Carpenter writes:

Thank you for going to the trouble of making your guide easily available to and usable by the community.

On 2/25/21 8:28 PM, Abhilash Raj wrote:

...

Is there a specific reason that you chose to go with an entirely new doc

Yes. Just from observing the communications on this list, there are multiple ways to install Mailman 3

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.

My guide represents a very stable and easily maintained environment for me and hopefully others.

I'm pretty sure that there are quite a few folks with very similar installations.

Is there an official guide? See that is the problem.

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.

I did not know there was an official guide. Because every time I tried finding documentation in the past using Google searches, I got fed outdated information. So for me the guide that I came up with, works great for me and if no one else uses it, I certainly will.

...

Is it something about the contribution process to the official documentation that makes it hard

...

Well I don't know much about any of the above approach to documentation. So I would say that is a hindrance.

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.

...

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.

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.

The Dart Sass section came from Mark's comments on this list.

Now, automatic conversion of Mark's posts to reST documentation is a problem I wish we could get those Red Army AI programmers to work on!

Steve

-----Original Message----- From: Abhilash Raj <maxking@asynchronous.in>

Is there a specific reason that you chose to go with an entirely new doc rather than helping to improve the existing one? Several parts of it (at least the ones that official guide covers) seems similar to me and is duplicate information that at least two people are going to spend time writing and maintaining in future.

The official guide is for people who really know what they are doing (including those wanting to use Mailman on various existing systems). Mark's helpful articles are useful but also assume a certain amount of prior knowledge.

I just need instructions I can follow to start from scratch on a new VPS. I don't mind whether it is for Linode and Debian, Digital Ocean and Ubuntu, or whatever.

If this is the "idiot-proof" guide I mentioned in an earlier thread then it's a very welcome development for Mailman 3.

Best wishes

Jonathan

On 2/26/21 6:55 AM, Andreas Barth wrote:

• Lars Schimmer (l.schimmer@cgv.tugraz.at) [210226 10:15]:

...

On 26/02/2021 00:55, Brian Carpenter wrote:

...

I have finished my how-to install Mailman 3 on Debian 10 completed to the point where you can use it to get a fully functional Mailman 3 environment up and running. This is a comprehensive guide that walks you through installing EVERYTHING (currently!) that Mailman 3 needs to run. It also makes updating Mailman 3/Postorius/Hyperkitty very easy. I have not added the update directions yet but will very soon. I also plan on adding a section on setting up DKIM and Xapian with Mailman 3.

I hope this helps those who wish to get a Mailman 3 server up and running quickly and brings a sense of sanity to the confusion regarding the various documentation out there concerning the installation of Mailman 3/Postorius/Hyperkitty. I intend to add a How-to for Ubuntu 20 at some point.

Without further ado:

https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10

I am sure the above guide can use improvements. Feel free to contact me off-list to point out mistakes/improvements, etc.

Hm, it completely ignores the standard way for Debian: apt-get install mailman3-full also exim4 as standard mailer. And apache2. That's how I did it (for my first installation), and it worked out of the box. However I would recommend to directly use a real database (e.g. postgresql).

Andi

---

Except my How-to will give you the latest stable versions of Mailman 3, Postorius, and Hyperkitty and PostgreSQL instead of sqlite.

-- Brian Carpenter Harmonylists.com Emwd.com

On 2/26/21 1:19 PM, Andreas Barth wrote:

Re the "latest greatest", that's always the same question for all software. If one is happy what comes from the distribution, I always recommend to use that (or just use the currently developed stable version, i.e. testing or unstable, perhaps even only for these packages). If one needs something newer / else / specific local patches, it's good to have documentation that helps.

We're not talking bleeding edge here (although the server that supports this list and the python.org lists is bleeding edge). We are talking about installing the current releases from PyPI. 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.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 27/02/2021 04:02, Stephen J. Turnbull wrote:

Lars Schimmer writes:

...

Hm, it completely ignores the standard way for Debian: apt-get install mailman3-full also exim4 as standard mailer. And apache2.

Right. The idea is that Debian is a *component* of *Brian's* system, not that Brian is installing a Debian system. One problem is that a lot of people like to run Debian Stable, which lags our releases by many months, sometimes a couple of years. A lot of people run a Debian Stable system plus a couple of mission-critical apps from source or from upstream repositories.

Maybe the debian packages are old because people do not care about and use always upstream because debian packages are old? I do know lots of software projects with recent debian packages for stable, testing and unstable. Esp. in the wide use of debian based systems all over the internet. One reason to run those system is the easyness in install and the stable function of its component. Not to need to install all software from upstream because no one cares about a recent package.

It's not necessary to "keep up" to be very helpful to our users, of course. But I think Brian's document is likely to be the "gold standard" for a while. I understand why Abhilash wants it in the official docs. :-)

If it should be a gold standard, it should mention the default setup of a standard debian system (which is exim4, btw) and not assuming a special setup debian system.

Steve

MfG, Lars Schimmer

TU Graz, Institut für ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723

On 3/1/21 3:10 AM, Lars Schimmer wrote:

If it should be a gold standard, it should mention the default setup of a standard debian system (which is exim4, btw) and not assuming a special setup debian system.

So why don't you write up your own how-to for your so-call ''standard debian system". Remember this is a forum for Mailman 3, not a forum for the users of a "standard debian system". So far your comments are not helpful at all.

-- Brian Carpenter Harmonylists.com Emwd.com

--On Tuesday, March 2, 2021 9:09 AM +0100 Lars Schimmer <l.schimmer@cgv.tugraz.at> wrote:

On 01/03/2021 13:15, Brian Carpenter wrote:

...

On 3/1/21 3:10 AM, Lars Schimmer wrote:

...

If it should be a gold standard, it should mention the default setup of a standard debian system (which is exim4, btw) and not assuming a special setup debian system.

So why don't you write up your own how-to for your so-call ''standard debian system". Remember this is a forum for Mailman 3, not a forum for the users of a "standard debian system". So far your comments are not helpful at all.

Install debian

apt-get install mailman3-full

As someone who is stuck using the ancient version of mailman3 in debian, I have to disagree. 99.9999% of the time I hit an issue, it turns out it was fixed years ago, but because I use the debian maintained version, I don't have those fixes. It's horrible.

Distribution packages tend to be useful for really basic things like libraries. For constantly evolving projects where you need to be current, they're more of a detriment.

--Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

On 02/03/2021 19:20, Mark Dadgar wrote:

...

As someone who is stuck using the ancient version of mailman3 in debian, I have to disagree. 99.9999% of the time I hit an issue, it turns out it was fixed years ago, but because I use the debian maintained version, I don't have those fixes. It's horrible.

So, why does someone not care about the debian package to fix that bugs? It is possible, and is done by other packages every day.

+100

I originally installed mailman3 via the ubuntu packages and I eventually replaced that setup (read: paid Brian to re-install mailman3 “correctly") for 2 key reasons:

1. The ubuntu (and presumably debian) packages are 1+ years out of date - Quanah is correct in that most of the bugs you hit have been fixed already but haven’t made it through the package maintainer process yet.

Just being 1+ years old does not tell you a software is bad or not useable. Thats a nonce. Bugs shoudl be iron out with package fixes, if someone cares about. New versions are out, needs to be tested.

2. The package installs are non-standard with respect to the way the mailman3 community tends to install them, which makes getting support here on this list much, much harder. You can see evidence of that periodically when someone asks a question and Mark’s response starts with “I’m not entirely sure how the <distro> package sets things up, but …”, which is no slight on Mark because he has his hands full with mm3 already and tracking every distro install layout is just not going to happen. It also means that the official mm3 docs don’t match what came out of your package. It’s just not good all the way around.

Sure, every software has its own scheme, but sthats what standards are for. I still cannot switch easy between fedora, debian and other distros due to different standards on file path. It is a nightmare. Thats why I like to stay with 1 standard for all softeare packages on one system. I do not want to run 20 software distributions with 20 ways of doing it the right waay (tm). You are right, the dev of a software should mostly care about fixing bugs, implementing new features and getting along with the software. Implementing different ways of installing is just a side topic. But someone should care about howto get the (useful) software to the masses for using it. And that position should care about howto implement the software good into the running distributions worldwide. And for distributions with a very good way of using packages, it is a nightmare to work beside the package manager just because the package is rather not well maintained.

...

Distribution packages tend to be useful for really basic things like libraries. For constantly evolving projects where you need to be current, they're more of a detriment.

So much this.

You do not need a bleeding edge software on production servers. You just need bug free, whihc is easy done with packages on distributions, if maintainers do it well enough.

For a testing server bleeing edge maybe fine, but not in production.

• Mark

---

mark@pdc-racing.net | 408-348-2878

---

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

MfG, Lars Schimmer

TU Graz, Institut für ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723

Bottom line, I think Abhilash is right: we should emphasize the pip install (probably into a venv) as the "best supported" install. Perhaps we can prioritize being more systematic about documenting the various approaches, not in term of the details (although that's a "nice to have"), but with respect to the advantages and disadvantages of the various install methods.

Comments welcome.

A few comments on the distro installs for the Mailman nerds:

Mark Dadgar writes:

2. The package installs are non-standard with respect to the way the mailman3 community tends to install them,

To be fair, *most* of the differences with Linux distros is that Mailman uses a "classic" $prefix-style install into $prefix/usr and $prefix/var, while the distros follow the FHS (File Hierarchy System) layout. The FHS layout in many ways is more closely-specified, and more maintainable at the distro and system levels, but it requires more effort than just throwing files into a set of more or less reasonably organized directories. Mailman 3 now provides an option for (better) FHS conformance at installation, which should reduce this problem over time.

Most of the rest have to do with protecting config files from overwriting by distro upgrades. That is annoying, because location of config files is a frequent question in support, and also can lead to duplicate config files (and "great fun had by all" :-/ ) if the admin follows the recommendation of the "wrong" documentation.

...

Distribution packages tend to be useful for really basic things like libraries. For constantly evolving projects where you need to be current, they're more of a detriment.

So much this.

I agree. But I prefer to phrase it as "mission-critical features are evolving" rather than "constantly evolving". I suspect there are a lot of people who have a casual need for a few mailing lists, and will do fine with Mailman 3 from $DISTRO stable or LTS. :-)

The thing is, I think those folks will find "apt-get mailman-suite" or "yum mailman-suite" with no help from us. And I agree that the differences between the organic evolution of Mailman setup within the project and the distros' FHS-based installs are a real consideration if Mailman is a mission-critical application for you. On the other hand, Brian's "greenfield setup of a server specialized to Mailman" is probably a minority interest (ie, in terms of the number of site admins involved -- it probably serves a majority of subscriptions!)

Steve

Lars Schimmer writes:

Intereting view for a software poackage taking a few years to get a way to migrate from mailman2 to mailman3. Or in other words: if a stable version is not useable/to old, the software is not production ready.

Not our problem though. It was the distro's choice to provide Mailman packages. We're happy that they're interested, and happy to do what we can to support their users when they come here. But it's up to them to judge whether their packages are useful to their users.

...

For constantly evolving projects where you need to be current, [distribution packages are] more of a detriment.

Nope. Vote against this view. You need a stable system to rely on and setup without hassle in a nonce.

Then what are you doing here? That is not Mailman 3, as you can see from reading this list. Once working, Mailman 3 is quite stable as long as you understand the parameters (for example, what a shunted message is, and what configurations are available from Postorius and what requires shell access). But it is not yet hassle-free to set up (unless you use Brian's guide on an otherwise empty host ;-). Mailman 3 is still a work in progress, with a wide variety of requirements from our users that only we can address.

And again in <428b33e6-189b-3a13-0bab-b5d77735d8ab@cgv.tugraz.at>:

So, why does someone not care about the debian package to fix that bugs? It is possible, and is done by other packages every day.

Not our problem. Ask the Debian maintainer, who is not a core Mailman developer.

Thats why I like to stay with 1 standard for all softeare packages on one system. I do not want to run 20 software distributions with 20 ways of doing it the right waay (tm).

I doubt anyone disagrees, but yet again, not our problem. Our problem is that y'all choose 20 different software distributions and somebody among you wants to run Mailman on each one of them, embedded in an equally wide variety of network configurations.

You really should be over on some Debian list with this thread. I understand your frustration, but we have no obligation and no intention to do anything about it. We're here to maintain Mailman itself and never said anything else. If the Debian maintainer has specific requests of us, I'm sure all of us would take a strong interest in that. But maintaining the Debian packaging itself is his/her chosen job, not ours.

Steve

On Tue, Mar 2, 2021, at 9:12 AM, Stephen J. Turnbull wrote:

Lars Schimmer writes:

...

On 27/02/2021 04:02, Stephen J. Turnbull wrote:

...

...

It's not necessary to "keep up" to be very helpful to our users, of course. But I think Brian's document is likely to be the "gold standard" for a while. I understand why Abhilash wants it in the official docs. :-)

If it should be a gold standard, it should mention the default setup of a standard debian system (which is exim4, btw) and not assuming a special setup debian system.

"Gold standard" means it does what it sets out to *really* *well*. "Gold standard" does not mean it does everything everybody wants. In particular, much of the appeal of Brian's guide is that it's how he sets up a Mailman 3 host, and he's proved it's repeatable, many times. Anything that he doesn't use himself doesn't belong in his guide.

We already have a descriptions of Exim (which I wrote the original) and Apache setups in the "official" docs. There's no good reason to treat Debian specially, since we don't distribute .debs ourselves. It's not even clear that we should recommend apt-get mailman! And surely no need, as that is the obvious (but not necessarily best for any given server!) way to set up a Debian Mailman installation. But there is good reason to believe that typical Debian installations will be quite out of date, because most admins prefer to run a server based on stable or LTS distros, not bleeding edge (Debian "sid") or even beta (Debian "testing") distributions, while updates to Mailman continue to be frequent and important to many or even most users.

Also, FWIW, we do point users to Debian packages in the docs1 and don't mind pointing users to other distro packages either.

One thing I do want to clear out is that in my emails when I say "official install guide", my focus is primarily on installation using "pip". There are some distro level packages that even "pip" cannot install where we have to get specific and say, install this package when on debian/ubuntu and such. Like Steve mentioned earlier, Debian is just a part of the setup process because we rely on some packages like Postfix, Nginx, GCC etc.

It is _relatively_ easy to update/maintain the "pip" installation guide for more distros where we provide instructions specific to Mailman and ask users to install the system packages that Mailman needs. My mantra with this2 specific install guide is to be thorough enough for someone to setup latest Mailman 3, but doesn't care about which Linux distro they use, using pip on a Debian system (because that's what many of the developers use) but have enough pointers for someone using a different distro.

The "default" choices are simply based on what we run and can provide some level of support for on this list.

-- thanks, Abhilash Raj (maxking)