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
duplicate deliveries.
- 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
list.
- 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
password reminders.
- Provide an email interface to all administrative commands
- Add -join and -remove addresses for easy subscription,
unsubscription
- 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:
http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotOneFeel free to contribute.
-Barry
[*] 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.
Hi Barry, A fellow student of mine is working on getting full name support for mailman addresses. Is there a way we can get that in with the 2.1 release? I will keep you updated on his progress and send in a patch once that is done.
Thanks for all the great work.
Nick
"Barry A. Warsaw" wrote:
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 duplicate deliveries. - 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 list. - 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 password reminders. - Provide an email interface to all administrative commands - Add -join and -remove addresses for easy subscription, unsubscription - 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:
http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotOneFeel free to contribute.
-Barry
[*] 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.
Mailman-Developers mailing list Mailman-Developers@python.org http://www.python.org/mailman/listinfo/mailman-developers
-- Nicholas Marouf http://www.ramallahonline.com
participants (2)
-
barry＠digicool.com -
Nick Marouf