[Mailman-Users] Mailman on Mac OS X Server 10.3: Outgoingmessagesstuck in qrunner/in folder

[Todd Zullinger]

Brad Knowles wrote:
> At 10:20 PM -0500 12/14/06, Todd Zullinger wrote:
> 
>>  But what value would MacOSX specific integrations be to the
>>  Mailman project?
> 
> Well, if they fed their changes back to us, that would allow us to
> incorporate that into future versions of the software, which would
> then be trivially easy for the vendor to upgrade to.  Apple would no
> longer have to maintain their own proprietary modified version.

It seems like that'd get to be a lot of work maintaining vendor
specific integrations.

> So, yes -- I think that there is a very strong benefit to the
> vendor, if they contribute their code back to the project.

Code is one thing, vendor specific integration is another.

> If there are things that need to be done to get Mailman to fit
> better into the FHS, and they aren't just the minimum changes hacked
> in but are appropriately and fully integrated into the software, I
> see no reason who those contributions would not be warmly welcomed.

They're part of the design goals for MM3.  I'm not sure what the
status is for 2.2 and I wasn't able to find any hits for FHS on
wiki.list.org, but I may very well be doing something completely wrong
there. :)

I don't think John's changes were of the hacked in variety, but the
changes are enough that they haven't been integrated into the current
2.1 branch, though the patch was submitted in 10/2004.  I think it's
simply a case where those changes were very important to Red Hat (in
that FHS compliance helped with other distro issues like integrating
SELinux access controls) but they weren't important enough to the
broader community of Mailman contributors to warrant making the
changes in the 2.1 branch.

Nothing wrong with that.  It's why open source is so nice.  I have the
choice to find vendors and projects that share more of my values than
others may.  If FHS compliance is really important to you, you'll like
the Red Hat mailman packages.  If you prefer simplicity and less
scattering of your files, the stock mailman install will suit you
better.

John's message and patch are in the mailman-developers archives here:
http://www.mail-archive.com/mailman-developers@python.org/msg08110.html

> Unfortunately, a lot of the changes most people submit are of the 
> hackish variety.

That sounds like a good reason not to ache for too many more to me,
especially if they're just vendor specific tweaks. ;)

>>  To me it makes a difference what sort of modifications you're
>>  talking about.  Most of the modifications in this thread and
>>  similar threads deal with changes a vendor or distro make to
>>  integrate mailman into their specific way of doing things.  And I
>>  think those changes aren't likely to be useful to the project as a
>>  whole.  So that's the part where I think it's unfair to criticize
>>  vendors and distros over.
> 
> Actually, I think it's just as valuable for a vendor to contribute
> those changes back to us as ones that actually have to do with core
> functionality.
> 
> This way, when someone comes to us with a problem on platform Y, we
> can look into the code and see where platform Y puts things, and we
> can give them a straight answer as to where the log files are, where
> the commands are, etc....  Otherwise, our only option is to say that
> the Mailman-standard location for a specific file is mumblefrotz,
> and that it's up to the questioner to figure out what this means for
> their platform.

Well, many of the changes that are made to the way mailman is
installed aren't really in a format that a vendor or a distro can send
to the Mailman project as a patch.  These changes may be made in an
rpm specfile or a debian control file or countless other distro and
vendor specific methods.  Being inundated with all of that doesn't
help to support users better, IMO.

What helps is having people on the lists that know something about the
various distro and vendor packages that can point out where something
is to a new poster.  Having used Red Hat systems for a number of
years, I'll sometimes chime in when someone posts and says they have
mailman-2.1.5-35 on Fedora or something like that, recognizing that
they've got mailman installed via rpm.  To help someone find out where
mailman's parts are installed requires knowing a little about the
package management system - unless mailman started shipping with a
script in a standard path that you could point to and say, run
"mailman_where_are_my_parts" or something. :)

>>  My point mainly is that it sometimes comes across that vendors/distros
>>  who install mailman and add to or change it to integrate it into their
>>  system gets painted as doing something wrong.
> 
> When they do that without contributing back to us whatever changes 
> they've made to the Mailman code or scripts, the locations of files, 
> etc... then I think that they have done something wrong.

That's a much broader view of the requirements of the GPL than I
subscribe to.  Changing install paths should be easy to do via
configure.  And if it's not and someone has to change the code to
alter the paths, that's something that ought to be fixed in the
mailman configure scripts (something akin to the FHS patch).

Changing the code in other ways is also allowed as long as those whom
they ship the code to have the right to the source.  That's the letter
of the license as I understand it.  And I agree with you that I don't
much care for that as it does skirt the spirit of the license.  I
don't think that's the category that most vendor tweaks fall into
though.  They are likely in the former.

>>  Ideally a few Apple users would hang out on this list and could help
>>  to guide those who are asking for assistance and using the Apple
>>  installed Mailman.  In that way, we'd all learn a little more about
>>  how to solve people's problems with Mailman.
> 
> Or maybe Apple could actually provide some actual support to their 
> customers who've paid real money to get MacOS X Server.

Well, yeah.  That'd be even better.  But since I don't give any money
to Apple, I'm in no position to demand that they do anything for their
customers.  There's nothing wrong with making customers aware that
they should expect support if they've paid for it, of course.

But if someone posts here and others can help them out, all the better
as the knowledge goes into the list archives and FAQ.

> I think your suggestion is more likely, because there are a couple
> of people in this situation who have done at least some of what you
> have suggested.  I just don't think that it's fair to put on their
> shoulders the whole sum total of providing support for all MacOS X
> Server users who need help with the Apple-provided version of
> Mailman and who cannot get Apple to give them the support that they
> deserve.

I can't speak for Apple, but my experience using Red Hat and Fedora
has been very good.  I've found the community forums quite helpful at
solving many problems.  The users that get help in that way often
never end up here, so we don't see how helpful the vendor/distro
channel may be.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
======================================================================
The worth of a state, in the long run, is the worth of the individuals
composing it.
    -- John Stuart Mill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-users/attachments/20061215/98ad4377/attachment-0001.pgp