On Thu, 02 Jan 2014 16:01:02 -0600 "Barry S. Finkel" bsfinkel@att.net wrote:

On 1/2/2014 8:42 AM, Gary Algier wrote:

...

Hi,

I just installed a new Mailman (2.1.12) server on Centos 6.4.

One question I have had for a while - As 2.1.17 is the latest release Mailman, why do people do new installations with versions that are old?

2.1.12 released 2009-02-23 2.1.17 released 2013-11-23

I did Google searches, and I found that CentOS 6.4 was released May 23, 2013 and contains Mailman 2.1.12.

CentOS prefer stability, #like other enterprise distros for latest updates use *buntu, fedora etc..

Regards, Frank www.frankly3d.com

Barry S. Finkel writes:

When I was working as a systems programmer with an IBM mainframe,

Interesting anecdote, but it addresses the wrong end of the issue. We already know that distros should keep their packages up to date. The question is why that doesn't happen. This:

When I was managing a Mailman installation, I kept Mailman up-to-date, because I never knew when one of my lists would encounter a bug that had already been fixed.

leads to a more interesting question: And to which distribution did you contribute package control files to allow all the users of that distribution to benefit from your work? And did they immediately install them, or did their QA group dither about testing them for months?

What we try to do in XEmacs is allow the upstream developer to commit directly to our package repository. But even then not all do, and we don't really have a QA process (except for beta testing, so in practice we're never out of beta for most packages :-). Few users are willing to contribute maintenance, although many contribute "first draft" patches and even whole packages.

It's not an easy problem.

Barry S. Finkel writes:

I was using Ubuntu, and my management told me that I had to install a package.

Aside from the fact that it made work for you, did you disagree with that decision? I don't (although I don't practice what I preach, I admit -- but I would if I was maintaining a Mailman installation for an organization rather than for a personal host, or if I didn't change distributions frequently enough that learning packaging systems is more annoying than it's worth).

So I spent some time learning how to take the Debian/Ubuntu package, merge the current SourceForge source, and generate a new package. I have posted on this list that I did this. Only one person has requested info on what I did.

Which is not surprising. Few people are working for enlightened managements like yours. (Individuals like me are likely to shortcut that step, you really do need a management, and an enlightened one at that, in the picture.)

But posting here, although generous (I'm not being sarcastic) of you, was way insufficient, you see. :-) What in an ideal :-P world you would have done was to post that information to the Debian (or Ubuntu) Mailman packagers, along with reviews of the existing patches, test cases demonstrating that Mailman DTRTs without the patches you propose deleting, and documentation (reviewed and revised, or new, as appropriate) for the patches you propose to continue. Then followed up with the discussion. Yeah, right, like you have the time or expertise to do that. And if you think a simple contribution of your working version of the deb-control files would mostly be ignored, I think I agree with you.

But you know what? Barry himself is a Canonical employee (at least, the last time he mentioned his employment status to me he was), but his time is considered too valuable to allow him to maintain Ubuntu's Mailman package!

You could argue that there's something wrong with a world where Barry isn't *assigned* to package Mailman (or perhaps the responsibility to make sure somebody does an excellent job of it). I could rebut but not with total confidence, and it's way beyond the scope of this discussion.

All I really want to do is to firmly nail down the proposition that in practice you cannot expect distros to be up-to-date in *all* their packages (and therefore must accept lags in packages important to you sometimes), and make it plausible that they have sufficient reason to allow substantial lags for some packages at any given time.

The problem I had with the Debian/Ubuntu package, besides the fact that it was not the current version and that help might not be available via this mailing list, was that there were a large number of patches installed by the Debian support group.

I agree, that is a problem. To the extent that they change Mailman's behavior (eg, the execrable mailman-to-postfix script) they make our job harder (yours ;-), mine, and most especially Mark's).

Most of those patches were not documented,

Some Debian package maintainers have sucky processes, and some packages don't actually have maintainers, but some poor sucker who believes that packages should be kept reasonably up-to-date, and volunteers to do so for several packages that he or she doesn't know all that much about.

Fixing this requires more labor. Ideally, the process is so sucky that a new process that requires *less* labor to review, *test*, install, and *document* patches, remove unnecessary patches, and inject into the distribution process can be designed. Still, doing that redesign requires a substantial amount of time invested in process management, both by the maintainer and by a mentor. And sometimes the process is reasonably streamlined for the work it does, but needs to do more work (eg, adding docs). This may require the "eclectic" type of maintainer to abandon some of their other packages. That's not a happy ending for all!

The problem, as I see it, with the Debian method is that when Mark announces a new release of Mailman, the Debian support group has to spend time re-fitting their patches. The ONLY Debian patch that I kept was one that placed the Mailman libraries in the proper directories for Debian/Ubuntu.

Doesn't surprise me. But for one example, I suspect the Debian Mailman package maintainer(s) disagree about the usefulness of the mailman-to-postfix script. Most of the regulars here (where "regular" is defined at least to include you :-) have the inclination and necessary knowledge to configure their MTAs by hand. Debian clearly believes that is *not* true of their "customers", which is why they installed that script.

Ironically enough, that script was written for the *convenience* of someone (Bruce Perens?) who was adept at maintaining his Postfix aliases, and so didn't need the script to be 100.00% robust. And it wasn't and it isn't. :-P

All in all, a *very* hard problem.