[Mailman-Developers] Towards 2.1
Barry A. Warsaw
Wed, 22 Nov 2000 00:02:26 -0500
There have been lots of great discussion on mailman-developers about
the directions Mailman should be taking. This is all very cool stuff
(and I want it to continue), but I view it as being more for Mailman
3.0, for which I have no time frame at the moment.
Now that 2.0 final is imminent[*], I'd also like to open up some
discussion about what we want to see in 2.1. My hard commitment, long
overdue, is to integrate Juan Carlos's and Victoriano's I18N work.
Juan Carlos has sent me patches, which I intend to start unpacking and
looking at, probably after the US Thanksgiving holiday weekend. I'd
also like to start using some of the nicer Python 2.0 features to
clean up the code in places.
Other than that, I'd like to get people's feedback on the really
crucial stuff that needs to get fixed for 2.1. I want to keep to a
bare minimum anything that requires re-architecting, pushing that into
3.0 after more discussions. I'd like to try to get a 2.1 beta out by
the end of the year, with 2.1 final some time in January. I don't
know if that's realistic or not.
From the TODO list, things I can imagine tackling for 2.1 include:
- Plain text digests should conform to RFC 1153.
- If a message has MIME parts and the header/footer is going to be
added, the message should be transformed into a mulitpart/mixed
with the header and footer added as text/plain parts.
(note that this will require improving Python's standard MIME
message handling. b.bum astutely <wink> observes that it
basically sucks right now and fixing this dovetails with work i
want to do for Python 2.1 as well).
- Allow "urgent" postings to all members by the list admin which
bypasses normal digest delivery.
- A button that will bundled and deliver a digest Right Now.
- Allow the list-admin to require approvals for unsubs
- Allow the user to be excluded from postings if they're getting
them in the to: or cc: headers. Be smarter about filtering out
- Allow users to subscribe without selecting a password and have
Mailman create a password for them.
- Allow the site admin to define list styles or themes, and list
admins to choose one of the canned styles to apply to their
- Full creation, deletion, renaming, etc. of lists through the web
(and email?), including fixing aliases file updates.
- add_members should have a switch to disable admin notifications
- Allow individuals to turn off password reminders
- Don't use the first public mailing list as the `originator' of
- Provide an email interface to all administrative commands
- Add -join and -remove addresses for easy subscription,
- For email subscribes, keep an audit of where requests are coming
from, and send the original request headers in the confirmation
message. Helps track down subscribe bombs.
- Support the `which' command.
- archive link should do *something* reasonable before the first
message has been posted to the list.
We should also do /something/ about qrunner, but again, I want to
keep radical changes to a minimum. Stability is crucial, but
performance counts too. Maybe Chuq's idea of splitting the queue
into 3 parts can be done without much disruption.
I don't think /everything/ can be done for 2.1, and maybe other people
have different priorities. I'm going to keep this list up-to-date on
the Mailman2.1 Wiki:
Feel free to contribute.
[*] The astute observer will notice the tarball on SourceForge
already. I'm waiting for the mirror sites to update, but will
announce tomorrow even if they don't.