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 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 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=.

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

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