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