On Thu, Feb 25, 2021, at 3:55 PM, Brian Carpenter wrote:

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

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.

On Thu, Feb 25, 2021, at 3:55 PM, 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.

This really does remind me of https://xkcd.com/927/.

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.

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 this1 repo and use Sphinx to build and REsT formatting (.rst).

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.

-- thanks, Abhilash Raj (maxking)

On Thu, Feb 25, 2021, at 6:38 PM, Brian Carpenter wrote:

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.

Great, thanks!

...

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.

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

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.

...

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.

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.

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.

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.

...

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.

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?

...

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.

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

-- thanks, Abhilash Raj (maxking)

• 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

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

• Brian Carpenter (brian_carpenter@emwd.com) [210226 13:29]:

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

...

...

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

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

The default debian way also uses postgresql if you install postgresql and make the relevant selection while installing mailman3-full (or later with dpkg-reconfigure).

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.

Andi

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

Stephen,

You can indeed select full unicode on a per database, (IIRC, even per-table basis).

The useful keywords for details are 'mysql' and 'utf8mb4'.

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

Ruth

On 27/02/2021 12:36, 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.)

-- Software Manager & Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/

jonathan.mailing.lists@gmail.com writes:

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.

Brian's guide is exactly what it sounds like you want, then. It's battle-tested in a large commercial service that has been around for a long time. He hasn't been using Mailman 3 at scale for very long (about three years, I think) but (almost) nobody else has used it at scale either.[1] Even Mark has only three or four separate systems (although he's probably up to about 100 or 150 lists running on Mailman 3; Brian has mentioned at least that many separate installations just this past week.

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

Be warned: nothing is proof against Internet mail. But with Brian's guide you'll be armored with a well-documented baseline.

Footnotes: [1] fedoraproject is huge, but I think they run all their lists out of one server, or server farm. Not the same level of experience as multiple installations.

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

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?

Eh, sorry, but stable means: only essential (i.e. security) bugfixes get into that version.

This is not a problem, it's a feature. If someone wants the latest greatest version of all packages, run testing or unstable. And if you need it for just one package, install the required package by hand. This works usually quite well.

The testing/unstable branch contains version 3.3.3 as of writing this which is the currently released version, see https://packages.qa.debian.org/m/mailman3/news/20210205T001903Z.html (and which was uploaded about a day after release - not a bad timing).

I would be quite careful speculating that someone may be not careing about something.

Andi

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

should be the default standard way to intall on a debian way, which whould be supported.

If software works around this for years, it is not really helpful for the users of the software itself. Reminds me of hugin, just doing source releases and keep the work on users to compile and make it useable.

I do appreciate the mailman3 work, and I do see the less ressources. But if the debian packages only appear after I wrote the maintainers to release a mm3 package for debian (the most used package format AFAIK), it looks like someone neglect those systems.

Also, if someone writes "the perfect standard way to install a softeare on debian" and neglecting the default setup of debian, it seems like it doesn't care about debian and the way people do use it at all.

The default way people do setup debian is exim4 e.g. and using packages, not software beside package system and provoking failures with poackage system while using those non packages.

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 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 Mar 2, 2021, at 9:31 AM, Quanah Gibson-Mount <quanah@symas.com> wrote:

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

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

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.

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.

• Mark

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

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

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

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?

Cheers,

Johannes

On 3/14/21 10:35 AM, Andreas Barth wrote:

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

Or even the latest stable releases from PyPI installed with pip which is what Brian's guide covers.

Mailman 3 is relatively new and still evolving. Even the latest packages in Debian sid, not to mention buster, are in some cases behind the PyPI releases. The packages from Debian buster are considered 'stable' but have issues which are fixed in the current PyPI releases.

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