add_members and nomail
Back in 2005, while working at an OS X Server-based organization, I wrote a bash + python script pair that extracted students/staff/faculty from a database to populate mailman lists, where many members were subscribed to various lists in nomail mode, using add_member's "-e" flag. The system worked very well.
Later, we dropped OS X Server and moved to Linux, and I was surprised to find that my script no longer worked. Only then did I realize that "-e" for "nomail" was an Apple customization that never found its way into the standard Mailman distribution. I solved the problem by copying the Apple-provided add_members to my Linux systems and changing the python shebang at the top.
These days, I find myself still doing the same thing on the cPanel-based systems I run, which means my systems break each time cPanel updates Mailman, and that I now run a very old version of add_members. Every organization I've worked for has had this need to batch-add people in nomail mode, which makes it really surprising to me that the standard distribution still doesn't support the option (I can't possibly be the only admin with this need!)
Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included?
Thanks, Scot
Scot Hacker wrote:
Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included?
Probably yes. The reason it was never include upstream is that Apple has *never* shared any of its Mailman changes with the upstream GNU-Mailman project.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
Scot Hacker wrote:
Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included?
Probably yes. The reason it was never include upstream is that Apple has *never* shared any of its Mailman changes with the upstream GNU-Mailman project.
Of course it has shared the changes.
What it never done is to provide free labor to liaison with Mailman and integrate its changes into Mailman. Personally, I can't blame them. Even in projects where I'm a core contributor it's often difficult to get my changes in in the form that I think is best, and my experience with contributing to projects I'm not a core member of have been downright miserable. "In-spected, ne-glected, re-jected, and de-jected"[1] being a common outcome.
If an assignment is the problem, that's still not a "failure to share" as defined in the open source community IMO. That's *our* failure to accept the sharing on terms that are accepted by every definition of "free software".
The Mailman team has every right to choose which which changes it will devote its labor to. But the changes *are* shared -- they're available both physically and legally. It's our choice not to provide labor, or not to accept universally acceptable terms. Please let's use more accurate rhetoric, and not cut off our nose to spite our face.
Footnotes: [1] With apologies to Alice and the Restaurant.
On Oct 19, 2012, at 11:52 AM, Mark Sapiro <mark@msapiro.net> wrote:
Scot Hacker wrote:
Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included?
Probably yes.
Ah - Just realized that the project is now on 3.x, but the fix I have is for 2.x (which is also what cPanel still provides). Looking at the 3.x, the project structure (at least for the command line tools) has changed radically. Is it still worth submitting a patch if I don't have anything prepared for 3.x?
Here's a simple 2.x diff in case it's useful to anyone: https://gist.github.com/3924229
Thanks, ./s
On Oct 20, 2012, at 11:06 AM, Scot Hacker wrote:
Ah - Just realized that the project is now on 3.x, but the fix I have is for 2.x (which is also what cPanel still provides). Looking at the 3.x, the project structure (at least for the command line tools) has changed radically. Is it still worth submitting a patch if I don't have anything prepared for 3.x?
I'd say a bug and a branch or patch would still be useful. Perhaps Mark will decide to apply this to the 2.1 branch, or someone else will port it to Mailman 3 some day.
Cheers, -Barry
On 10/20/2012 11:06 AM, Scot Hacker wrote:
Here's a simple 2.x diff in case it's useful to anyone: https://gist.github.com/3924229
Thanks.
I'm inclined to implement this for the 2.1 branch, but my taste is to do it differently. I would prefer to have a -n|--nomail option which if specified would set the added members to nomail by admin, the default in the absence of the option being current behavior. Thus, no need for --enable-mail=<y|n>.
Also, If the member to be added is already a member, I wouldn't change its delivery option.
Would such an implementation work for you?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Oct 22, 2012, at 7:15 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 10/20/2012 11:06 AM, Scot Hacker wrote:
Here's a simple 2.x diff in case it's useful to anyone: https://gist.github.com/3924229
Thanks.
I'm inclined to implement this for the 2.1 branch, but my taste is to do
Sorry for response delay - no time to learn bazaar and launchpad right now for this, so I appreciate your offer.
it differently. I would prefer to have a -n|--nomail option which if specified would set the added members to nomail by admin, the default in the absence of the option being current behavior. Thus, no need for --enable-mail=<y|n>.
Absolutely - anything that can be scripted easily would work fine for me, and for others too I imagine.
Also, If the member to be added is already a member, I wouldn't change its delivery option.
Hmm, not sure about that part - my implementation sometimes includes duplicate addresses, relying on the mailman import to weed them out. So I would *prefer* to have the option changed for existing members. But if that doesn't sit well with you, I understand - my script will just have to be smarter about it.
Thanks, Scot
Would such an implementation work for you?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-- Birdhouse web and mail hosting http://hosting.birdhouse.org http://about.me/shacker
Scot Hacker wrote:
On Oct 22, 2012, at 7:15 PM, Mark Sapiro <mark@msapiro.net> wrote:
Also, If the member to be added is already a member, I wouldn't change its delivery option.
Hmm, not sure about that part - my implementation sometimes includes duplicate addresses, relying on the mailman import to weed them out. So I would *prefer* to have the option changed for existing members. But if that doesn't sit well with you, I understand - my script will just have to be smarter about it.
I don't see this as a problem. If you try to add the same address twice with a --nomail option, the first add will succeed and set nomail and the second add will fail and do nothing, but the result is the address is added with nomail set.
The only situation in which this makes a difference is if the address is already a member without nomail, which would only occur if it was added previously by some other process or if it was added previously and the user subsequently enabled delivery. Either way, I think the right thing is for add_members --nomail to not disable delivery for an existing member.
Note, if you want to just set some or all users to nomail, see <http://www.msapiro.net/scripts/set_nomail.py>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Oct 23, 2012, at 11:06 AM, Mark Sapiro <mark@msapiro.net> wrote:
I don't see this as a problem. If you try to add the same address twice with a --nomail option, the first add will succeed and set nomail and the second add will fail and do nothing, but the result is the address is added with nomail set.
The only situation in which this makes a difference is if the address is already a member without nomail, which would only occur if it was added previously by some other process or if it was added previously and the user subsequently enabled delivery. Either way, I think the right thing is for add_members --nomail to not disable delivery for an existing member.
True - I guess it's only happenstance that my script subscribes the yesmail members first, then does a second pass for the nomail members. I could easily reverse this order in my script. Problem solved.
Note, if you want to just set some or all users to nomail, see <http://www.msapiro.net/scripts/set_nomail.py>.
Also a good option! Thanks for that.
./s
-- Birdhouse web and mail hosting http://hosting.birdhouse.org http://about.me/shacker
participants (4)
-
Barry Warsaw -
Mark Sapiro -
Scot Hacker -
Stephen J. Turnbull