[Mailman-Developers] Towards 2.1
Nick Marouf
marouni@earlham.edu
Wed, 22 Nov 2000 00:53:06 -0500
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/MailmanTwoDotOne
>
> Feel 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