[Mailman-Users] Re: mailman v2.x
I wrote a long screed, full of piss and vinegar. But on reflection, clearly nobody is reading what I wrote earlier, so let's try pithy and dry. It's still long. :-( Chip Davis writes: > OK guys, what's really going on here? I don't know. I can tell you I'm done with Jim. You'll have to ask him about what he thinks is going on. I have differences of opinion with you and Carl, but no quarrel. > Is this about turf? Not on our side. I have genuine concerns. In Mark's most recent post, he writes: > We only asked that these potential new members actually ask to join > the GNU Mailman project as members. That doesn't look like a concern with turf to me. Mark may not have the same concerns I do, or any at all, I don't know. We'll have to wait until he gets back. In the meantime, I'll lay out mine. > Is there something about Jim's proposal that requires resources > (money, proprietary code, prestige, etc.) from the GNU Mailman group? Mailman is a GNU project. Under the GPL, Jim's proposal *needs* no resources from the GNU Mailman Project, and no blessing from us, either. He has the code, and the physical resources are easy to come by elsewhere. Certainly it makes economic sense to use the existing repository and other project resources to support further Mailman 2 development. It won't cost Mailman 3 or the Mailman Project anything to share. But nobody else has any *right* to any of those resources, and especially not to the time that Mark and I devote to user support. If you think otherwise, you are wrong both as a matter of law and as a matter of free software philosophy. In this connection, Carl Zwanzig writes: > it's vastly different to say "Pay no attention to that GPL, > no one is allowed to maintain or improve that code." That's incoherent. The complaint is that people *are* maintaining and improving the code, but we don't allow them to use our resources and reputation to distribute their code. That complaint is groundless. It is fully within the GPL, letter and spirit, to refuse to distribute code, whether others' or our own. The spirit of the GPL is that you can use your own resources to distribute both your code and ours. Just ask politely, and if you want my support for you to freely commit to and distribute from the project's Mailman 2 branch, I ask you to commit to providing support for all its users. Or don't commit to serving users, just don't free-ride on the Mailman name and you can have my support. That was the idea of my original request to Jim. Back to Chip: > [Are you] genuinely concerned that the continued viability of MM2 > would be a threat to MM3[?] Brian may be, and I'd like to hear why. But at present I am not. My concern is that a small group of highly competent power users will take over the Mailman 2 repo, Mark and I will disengage from this list and Mailman 2 bug channels, and support for ordinary Mailman 2 users will go in the toilet because the new team is focused on developing an EOL application in an EOL language, not on user support. > I have a little experience [with multiple "branches" of REXX] here. With all due respect, I don't think it's relevant to what Jim has proposed so far. There's a detailed explanation in the "screed", but the gist is that Mailman 2 and Mailman 3 use completely different architectures and interfaces, so expertise simply doesn't transfer between them. Of recently active developers only Mark and I have experience with both code bases, and I at least want to wash my hands of Mailman 2. AFAICS, the developer teams will have little to talk about with each other. As far as the communities go, perhaps we could work together somewhat. We have a common history, we support the same kind of admins and list users, there's going to be movement across the Mailman 2 vs. Mailman 3 boundary. We share the goal (for us, secondary) of providing good day-to-day support to folks still using Mailman 2. But all Jim has proposed so far is to commit and distribute his team's patches. I don't mean to be unnecessarily unpleasant: that's a fact. You've all paid lip service to the Mailman 2 community, but are you committed to community support? Who's going to moderate this list? Who's going to be here day in and day out answering both interesting bugs and boring FAQs? What is to be done about users whose preferred distros EOL their Mailman 2 packages? > I can see that it won't immediately lift the entire burden of MM2 > off of Mark's shoulders, As far as Mark is concerned, Mailman 2 is EOL. So it's an objective fact that this change doesn't lift burden, it *adds* burden: new code, new questions, new bugs, new releases. The question is whether Mark will feel free to quit supporting Mailman 2. I sure will -- there will be a new maintainer to point users at. > simply declaring EOL on MM2 and leaving thousands of admins in the > lurch. Mark has already declared EOL a couple of times, although in practice we (that
[Mailman-Users] Manual Update on Centos 7
Dennis Putnam writes:
> Since Centos 7 is way behind on mailman rpm (2.1.15 is the only
> available rpm) and mailman is currently at 2.1.34 I need to do a manual
> update. While I know how to install software, I am concerned that just
> doing a manual install from the tarball will mess up current
> settings,
Perhaps the most straightforward procedure is to backup mm_cfg.py and
the data in the archives, data, lists, logs, messages, and qfiles
folders under /var/lib/mailman. Then get the source rpm, unpack it,
delete the old source tree and replace it with the new source tree.
Review the patches and delete any that apply to executable Mailman
code, keep only those that make the Mailman installation conform to
Centos layout. Fixup the rpm control file (Mailman version, build,
and list of patches), and build an installable rpm and a srpm. Then
install the rpm. Finally, check that the files backed up above have
not been corrupted, and start Mailman.
If you have to do a full manual install, I am not familiar with
Centos's layout, but the principles are the same for all distros. The
main issues that are common are
1. For Mailman itself, preserving and restoring the site config file
(mm_cfg.py), the list config files, and any in-process messages
(qfiles).
2. For system administration, the manual install layout is usually
different from distro packaging. For several reasons, we
recommend installing to /usr/local (and /var/local), which is the
default, because you will not overwrite any state, and it is easy
to recognize which files are "new" and which are "old" from the
prefix.
3. This means that you will need to adjust system startup
configuration and services like logrotate, your MTA, and your
webserver, to point at the new Mailman installation.
4. It is important to remove all of the original package installation
including state data such as qfiles to avoid confusing Mailman
and/or running two Mailman processes at the same time.
Check the release notes to see if there are any special
considerations between 2.1.15 and 2.1.34.
Outline of the procedure:
1. Get the list of contents of the installed package using rpm or yum
or whatever. It won't have the list configs, qfiles, logs, or
mm_cfg.py, but should have the directories where those things
live, as well as the code. This should also capture boot scripts,
logrotate configs, and if you're lucky MTA and webserver configs.
This is useful information if no RH/Centos people show up; I can
be much more precise about what you need to preserve and restore,
and how to do it, if things go sidewise. find /etc -name '*mailman*'
may help, but I expect those files will be in the rpm query
output. (The leading * is to catch '00mailman.sh'-style naming.)
2. zip (or tar) up the whole thing: any Mailman configs in /etc, the
Mailman code in /usr, and the list database, qfiles (if any), and
logs from /var. Don't forget init scripts or systemd services
under /etc/, logrotate configs, etc. This is a backup and
reference installation.
3. Use the default install of the new code. You can untar source
pretty much anywhere. /usr/local/src and /tmp are common choices.
Install to /usr/local and /var/local. Much safer than trying to
install to the /usr and /var hierarchies.
4. The global config mm_cfg.py can be copied directly from your
Centos installation to /usr/local/lib/mailman/Mailman/ or you can
put in it /usr/local/etc/mailman and symlink.
5. IIRC the var stuff goes in
/var/local/lib/mailman/{lists,qfiles,...}. Just copy the list
configs and queue files from the old install there. It's probably
not a good idea to recursive copy the /var/lib/mailman directory,
because it contains symlinks into /usr/lib/mailman, and also if
there's anything including hidden files in /var/lib/mailman/lock,
it's likely that Mailman will fail to start or worse, function
incorrectly.
6. Start the new installation, if it works you can remove the Centos
mailman package with rpm (or whatever).
7. You will have to fiddle with MTA, webserver, logrotate and init
script configurations to point to the /usr/local and /var/local
hierarchies instead of /usr and /var. How you do that on Centos
I'm not sure, but usually there are .d folders under /etc where
the sysadmin can drop local configs that will not be overwritten
by the package manager. Some manual editing will very likely be
necessary because some package configuration is normally done by
scripts that directly edit config files rather than dropping
include files in .d folders.
I'm sorry, even as long as it is that's pretty sketchy. But as long
as you keep backups of mm_cfg.py and the list configs, qfiles, and
logs you will be able to restart Mailman as it is now. If you install
to /usr/local and /var/local, you don't have to worry about
ove
[Mailman-Users] Re: mailman v2.x
I'm done, Jim. -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Manual Update on Centos 7
Since Centos 7 is way behind on mailman rpm (2.1.15 is the only available rpm) and mailman is currently at 2.1.34 I need to do a manual update. While I know how to install software, I am concerned that just doing a manual install from the tarball will mess up current settings, lists and members. Does anyone have experience doing this that can advise about pitfalls or has a cookbook document to do a safe update? TIA. signature.asc Description: OpenPGP digital signature -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: mailman v2.x
On 8/28/20 11:47 PM, Carl Zwanzig wrote: > > If the existing > gnu-mailman team doesn't want new members working on old code, and > that's the way it sounds, just say so and give the blessing for a code > fork. We never said that. We only asked that these potential new members actually ask to join the GNU Mailman project as members. Note: within the hour I am going off-line for 12 days so you won't hear more from me for a while. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: mailman v2.x
On Fri, 2020-08-28 at 23:47 -0700, Carl Zwanzig wrote: > > Or... it's pretty likely that MM2 maintenance, and maybe improvements, will > continue in some fashion. The question is whether that's under the auspices > of the gnu-mailman project or in a fork. If the existing gnu-mailman team > doesn't want new members working on old code, and that's the way it sounds, > just say so and give the blessing for a code fork. I'd love to hear RMS's opinion of that. -Jim P. -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
