From: "Adrian Bye" <adrian@tasmaniaconsulting.com>
Date: February 7, 2008 5:53:21 PM EST
To: barry@list.org
Subject: Fwd: [Mailman-Developers] Feedback for mailman developers
Barry,
Could you do me a huge favor and make sure this gets to the list.
It doesn't show up in the archives.
Warm regards,
Adrian
---------- Forwarded message ----------
From: Adrian Bye <adrian@tasmaniaconsulting.com>
Date: Feb 7, 2008 2:08 PM
Subject: Re: [Mailman-Developers] Feedback for mailman developers
To: Barry Warsaw <barry@list.org>
Cc: mailman-developers@python.org, rms@gnu.org, bmurdoch@lwb.org.au, tmihalicek@mihainside.com
, techsupport@meridian-ds.com, Peter Brown <peterb@fsf.org>
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,
-----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
--
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