[Mailman-Developers] Towards 2.1

[Barry A. Warsaw]

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.