Hi guys (and RMS, copied),
About 3 years ago I made this post:
http://mail.python.org/pipermail/mailman -developers/2005-February/017850.html
As a result, I get an email every 1-2 months from people asking for an updated patch.
I felt at the time it was an important project. I was told it was not, so I made it myself. And, it was refused to be added to the main fork of mailman which was quite frustrating.
Given the volume of email requests I get about it, my opinion seems to be confirmed. I wanted to bring it to your attention, and hope something will be done about it. These are just people who are figuring out my email address on the web and contacting me. There must be many more who don't actually ask me about it.
If another group wants to step up and improve mailman, it might be a good time to do so. This is a critical project which could become the centerpiece of a lot of important software if it was improved.
Best regards,
Adrian
Adrian Bye writes:
I felt at the time it was an important project. I was told it was not, so I made it myself. And, it was refused to be added to the main fork of mailman which was quite frustrating.
Actually, in the thread in the archives you were not told it was "unimportant", you were told it was a bad idea, that shouldn't be added to the Mailman mainline, and one prominent developer's bad experiences with a very similar system (which was implied to be more robust than yours is) were described. You didn't respond, so as far as I can see it was left out by default, not actually refused. There is a difference.
I see no reason why the reasons for not adding the proposed feature given in that thread have been invalidated. If you have significant experience with successes with your system, and are willing to describe it, and are willing to address the perceived defects in the light of your experience, I'm sure your patch will be reconsidered.
If you don't, declaring your patch to be "often requested" and "a necessary precondition for the resources needed to turn Mailman into a system capable of handling millions of messages a day" is not going to help your case.
Another way to put it is the Mailman developers all have a lot of successful experience with the policy of implementing standards and best practices. There's no standard here so experience is crucial to demonstrating best practice. Please report yours!
On Thu, Feb 07, 2008 at 12:52:07PM +0900, Stephen J. Turnbull wrote:
I see no reason why the reasons for not adding the proposed feature given in that thread have been invalidated. If you have significant
This patch includes two things, though: HTML headers and footers, and the 1-click unsubscribe. The HTML headers don't seem as controversial, beyond one incorrect help message, and could go in even if 1-click doesn't. I was thinking of adding HTML headers and footers, so I'm happy to shepherd that portion of the patch.
--amk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 7, 2008, at 6:25 AM, A.M. Kuchling wrote:
On Thu, Feb 07, 2008 at 12:52:07PM +0900, Stephen J. Turnbull wrote:
I see no reason why the reasons for not adding the proposed feature given in that thread have been invalidated. If you have significant
This patch includes two things, though: HTML headers and footers, and the 1-click unsubscribe. The HTML headers don't seem as controversial, beyond one incorrect help message, and could go in even if 1-click doesn't. I was thinking of adding HTML headers and footers, so I'm happy to shepherd that portion of the patch.
When Mark releases Mailman 2.1.10, I'd like to reopen the discussion
about Mailman 2.2. I'd like for us to consider moving all new
development over to that branch, which will allow us to be more
liberal about accepting new features, within the constraints of
Mailman 2's architecture of course.
I am planning on releasing an alpha of Mailman 3 by PyCon next month,
but it will still be lacking a web u/i so I think it still makes sense
to think about moving almost all current Mailman 2.1 work over to the
2.2 branch, while still maintaining Mailman 2.1 for security and
severe performance bugs.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHqvtO2YZpQepbvXERAvbpAJ9VbgT8Su7WOmYdlTpf3DEF76iVxgCfdp8o RQfh9pggeOBAjkCK7CUFtfE= =rflQ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote:
Hi guys (and RMS, copied),
About 3 years ago I made this post:
http://mail.python.org/pipermail/mailman -developers/2005-February/017850.html
As a result, I get an email every 1-2 months from people asking for an updated patch.
It looks to me like there are really two separate unrelated features
here. Distributing them in the same patch would make it difficult to
review, discuss, test and integrate, regardless of whether they are
good ideas or not.
I would like to encourage you to develop your patches in a different
way. I'm not making any promises about whether they would be
integrated if you do this, but it would make it easier for us to look
at, and I believe easier for your to maintain separately if you decide
to continue to do so.
I would highly recommend creating two separate Bazaar branches of the
Mailman 2.1 code. Each would implement just one of your features.
You could create a third branch with the whole thing if you wanted,
but I don't think it would be necessary. You should then register on
Launchpad and push these branches, publishing them in a live source
code repository for all to see.
I'm really trying to encourage this style of development. To me,
patches living in a tracker is dead code. With a published, public
branch, the entire process is more transparent, we can easily do a
merge and test if we wanted to look at it. We can even find these
branches easily via Launchpad. And you will have an easier time
maintaining them, because as new revisions get pushed to Mailman 2.1
trunk, you can just merge, commit, and push to update your own branch.
If you -- or anybody else -- has questions about this workflow, please
ping me on #mailman on irc.freenode.net. I will happily walk you
through it.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3 pcP+bzgjF1D1dIv89m8VLCY= =BC8W -----END PGP SIGNATURE-----
Hi guys,
I've copied 3 people who emailed me since May 2007 about this issue. I don't know any of them, they just found my post from 3 years ago on the web and wrote to me. Clearly its important to them since they emailed me about it.
Guys: I encourage you to subscribe to the mailman-developers list so you can communicate your needs directly with the mailman development team.
The one-click unsubscribe is a critical feature for mailman and will open up a much larger interest base. I am not proposing 1-click unsubscribe for discussion mailing lists such as this one - that would obviously cause problems with people unsubscribing each other by mistake. However a lot of organizations use mailing list software to broadcast newsletters to their membership. If users cannot unsubscribe via some kind of (simple) 1-click interface then it limits the people who can use the system and may not be CANSPAM compliant. The FSF is one organization that has been running a newsletter for a while and they have had to manually handle unsubscribe requests. Peter Brown is copied as well as RMS and may be able to respond if necessary.
When many users cannot unsubscribe from an announcement list (as the FSF used mailman for) they often don't bother, instead they just hit the "this is spam" button. Neither the sender or receiver notices anything when this happens. For the receiver, future emails from the list go into the trash, so hitting the "this is spam" button accomplished their purpose. The sender doesn't realise there was a problem because they never heard from the recipient. But the mail services know (eg hotmail/gmail/yahoo/aol) and they begin to mark the IP address/domain of the sender as a spam sender. This causes future WANTED mail from that sender to go into the trash.
When we were experimenting with mailman 3 years ago, we found that in fact mailman already has a bad reputation for email. We found our mail was directly going into the trash when it included mailman headers. When we modified mailman to send but hide the mailman headers, we got directly into the inbox. This testing is 3 years old, and I don't remember the specific services we were testing to, but it included one of hotmail or yahoo.
While mailman continues not to support easy unsubscribe in the footers, it will continue to hamper the growth of free software, as free software organizations will not have a reliable product to mail to broadcast to interested users. This demand is evidenced by the emails I get every 2 months from people asking me for this patch due to my emails in the archives from 3 years ago.
I'm not here to get into a debate - I only joined the list again to ask to have that post removed because I'm tired of responding to these requests which I cannot help with.
I hope this explains my point of view. Best of luck,
Adrian
On 2/7/08, Barry Warsaw <barry@list.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote:
Hi guys (and RMS, copied),
About 3 years ago I made this post:
http://mail.python.org/pipermail/mailman -developers/2005-February/017850.html
As a result, I get an email every 1-2 months from people asking for an updated patch.
It looks to me like there are really two separate unrelated features here. Distributing them in the same patch would make it difficult to review, discuss, test and integrate, regardless of whether they are good ideas or not.
I would like to encourage you to develop your patches in a different way. I'm not making any promises about whether they would be integrated if you do this, but it would make it easier for us to look at, and I believe easier for your to maintain separately if you decide to continue to do so.
I would highly recommend creating two separate Bazaar branches of the Mailman 2.1 code. Each would implement just one of your features. You could create a third branch with the whole thing if you wanted, but I don't think it would be necessary. You should then register on Launchpad and push these branches, publishing them in a live source code repository for all to see.
I'm really trying to encourage this style of development. To me, patches living in a tracker is dead code. With a published, public branch, the entire process is more transparent, we can easily do a merge and test if we wanted to look at it. We can even find these branches easily via Launchpad. And you will have an easier time maintaining them, because as new revisions get pushed to Mailman 2.1 trunk, you can just merge, commit, and push to update your own branch.
If you -- or anybody else -- has questions about this workflow, please ping me on #mailman on irc.freenode.net. I will happily walk you through it.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3 pcP+bzgjF1D1dIv89m8VLCY= =BC8W -----END PGP SIGNATURE-----
-- Adrian Bye Tasmania Consulting Group http://TasmaniaConsulting.com adrian.bye@tasmaniaconsulting.com Phone: 305-433-8188 Fax: 305-428-2665
Mailing address: 8260 NW 14th St, EPS-Y12457 Doral, FL, 33126-1502
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 7, 2008, at 1:08 PM, Adrian Bye wrote:
The one-click unsubscribe is a critical feature for mailman and will
open up a much larger interest base. I am not proposing 1-click
unsubscribe for discussion mailing lists such as this one - that
would obviously cause problems with people unsubscribing each other
by mistake. However a lot of organizations use mailing list
software to broadcast newsletters to their membership. If users
cannot unsubscribe via some kind of (simple) 1-click interface then
it limits the people who can use the system and may not be CANSPAM
compliant.
I can see that there is some merit to the idea for newsletter type
mailing lists. I think there's still the possibility of abuse because
such messages tend to be forwarded and those forwards will have the 1-
click unsub link. The only way I see of limiting that would be to
require a log-in to confirm the unsub, but then I guess you're in no
better shape.
I really wish more mail readers would support the RFC 2369 headers
directly. I think that would go a long way to making unsub as easy as
possible.
Having said all that, this is clearly not a feature for Mailman 2.1.
If some of the details can be worked out, it might be an option for
Mailman 3 where I think 'list styles' will help make configuration of
newsletter vs. discussion mailing lists much simpler.
Adrian, are you interested in creating the Bazaar branches as I
outlined previously?
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHq2eq2YZpQepbvXERAhRJAKCPGr9poibsagXH0MglKZFb+j8howCgkFhm h2GkWKJK1cZbhPOeQsl1kVg= =D2fp -----END PGP SIGNATURE-----
participants (4)
-
A.M. Kuchling -
Adrian Bye -
Barry Warsaw -
Stephen J. Turnbull