-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've successfully navigated the switch to Bazaar, it's time
to lay out plans for future Mailman releases. I've talked to several
people about what to do about Mailman's future and I'd like to take
this opportunity to describe my thoughts and get your feedback.
First some background.
Mailman 2.1 is (shockingly) four and a half years old, having been
initially released on 30-Dec-2002. The last release in the series,
2.1.9 was made almost a year ago. In the meantime, Mark and Tokio
have been doing a great job maintaining the 2.1 branch, with several
important patches in the tree now that will eventually become
2.1.10. The problem of course is that we can't add any new features
to the 2.1 family <wink>, so we should be thinking about a new major
release.
I've been making good progress on the SQAlchemy/Elixir version, which
will finally get rid of pickles and put Mailman on a Real Database
(tm). It's been clear to me for a while that this branch will have a
unified user database. It simply makes no sense to build the
database back-end without once and for all fixing this design
constraint. I've always said that the unified user database will be
in Mailman 3, and thus this branch is indeed called "Mailman 3.0".
I've been slowly building things back up from the ground floor. The
basic data model is in pretty good shape and I'm taking a religious
test-driven approach to making things work again. But the branch
still needs a lot of work, and I have no ETA for Mailman 3.0.
In the meantime, Andrew Kuchling and others have volunteered to work
on modernizing the Mailman web u/i, and Terri recently started a
thread discussing updates to the archiver. I think it makes sense to
bless these efforts, towards the goal of releasing them in Mailman
2.2. I intend to create an official Mailman 2.2 branch in bzr where
these efforts can land as they mature. My hope of course is that
we'll also be able to use much of this new code for Mailman 3.
I'd like to keep the changes for 2.2 focused on the web u/i and
archiver, with a small number of additional features to be
determined. Mailman 2.2 should see no changes to the basic
architecture or 'database'; we'll continue to use pickles by default
for Mailman 2.2. While I won't rule out other new features, I want
to be very picky about those that are accepted for 2.2, and would not
feel bad at all if we rejected or deferred until 3.0 most of those
proposed. Criteria for other 2.2 features must include minimal code
impact with a high degree of reliability and stability.
I plan on updating the wiki pages to reflect this thinking, but I
would like to get feedback from y'all about the plan. It would be
awesome if we could see a release of Mailman 2.2 some time in late
2007 or early 2008.
Comments, question?
- -Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 7, 2007, at 12:35 PM, Barry Warsaw wrote:
I intend to create an official Mailman 2.2 branch in bzr where
these efforts can land as they mature.
This branch is now live.
http://wiki.list.org/display/DEV/MailmanBranches
Cheers,
- -Barry
--On 7 July 2007 12:35:30 -0400 Barry Warsaw barry@python.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've successfully navigated the switch to Bazaar, it's time to lay out plans for future Mailman releases. ....
I plan on updating the wiki pages to reflect this thinking, but I would like to get feedback from y'all about the plan. It would be awesome if we could see a release of Mailman 2.2 some time in late 2007 or early 2008.
Comments, question?
All sounds very good. My two main problems with driving Mailman uptake here on campus are both to do with usability. The first is the current web interface, which was great when it was developed, but expectations have moved on. The second is the lack of a unified user database. So, it's great to see these items listed as the mail focus for 2.2 and 3.0 respectively.
WRT 2.2, I'd like to be able to offer something as simple to use as the list management features of Google Groups (which I use for some voluntary groups that I work with), but with the ability to expose additional functionality on request.
WRT 3.0, for enterprise and education purposes, it's important to be able to hook into existing authentication and authorisation mechanisms. For us, that means LDAP - at least for authentication. On the other hand, we also have external people using our lists, so we need to be able to either put them into an SQL database which will work in conjunction with LDAP, or to add a separate LDAP tree for them, or something similar.
Something that I've mentioned before, is the importance of preventing collateral spam. So, I'd like to be able to have my MTA ask Mailman whether a particular email address is permitted to post to a particular list, at SMTP time. I'm using Exim, which could call an external python script, but I'd rather be able to issue an SMTP callout to a running daemon, for efficiency. The callout would be executed after each "RCPT TO".
I plan on updating the wiki pages to reflect this thinking, but I would like to get feedback from y'all about the plan. It would be awesome if we could see a release of Mailman 2.2 some time in late 2007 or early 2008.
Comments, question?
All sounds very good. My two main problems with driving Mailman uptake here on campus are both to do with usability. The first is the current web interface, which was great when it was developed, but expectations have moved on. The second is the lack of a unified user database. So, it's great to see these items listed as the mail focus for 2.2 and 3.0 respectively.
WRT 2.2, I'd like to be able to offer something as simple to use as the list management features of Google Groups (which I use for some voluntary groups that I work with), but with the ability to expose additional functionality on request.
At our University we developed a customized mini Interface called 'simple' Interface. The normal mailman Interface is still there, called 'expert admin'. A (non working) demo is here: https://lists.uni-paderborn.de/listadm/demo.html The code does not use the mailman template system nor does it have multi language abilities. It even includes code specific to our installation. (We have a membership class that maps users to user in ldap and can create dynamic list with users from ldap + static users)
But maybe something like this should be included in future Mailman installation. Either a static simple interface or even a customizable simpe interface that is sufficent for 95% of the people (with well chosen defaults for your university/organisation)
WRT 3.0, for enterprise and education purposes, it's important to be able to hook into existing authentication and authorisation mechanisms. For us, that means LDAP - at least for authentication. On the other hand, we also have external people using our lists, so we need to be able to either put them into an SQL database which will work in conjunction with LDAP, or to add a separate LDAP tree for them, or something similar.
This is possible with mailman 2.1 with a self written Mailman Membershipt class. At least for List Member. If someone really needs this I could look into polishing the code and making it public.
Something that I've mentioned before, is the importance of preventing collateral spam. So, I'd like to be able to have my MTA ask Mailman whether a particular email address is permitted to post to a particular list, at SMTP time. I'm using Exim, which could call an external python script, but I'd rather be able to issue an SMTP callout to a running daemon, for efficiency. The callout would be executed after each "RCPT TO".
Same for Email that get rejected for spam reasons would be neat
Arne
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
It's catch up on email day!
On Jul 9, 2007, at 9:35 AM, Ian Eiloart wrote:
WRT 3.0, for enterprise and education purposes, it's important to
be able to hook into existing authentication and authorisation mechanisms.
For us, that means LDAP - at least for authentication. On the other hand,
we also have external people using our lists, so we need to be able to
either put them into an SQL database which will work in conjunction with LDAP,
or to add a separate LDAP tree for them, or something similar.
So, my standard answer to this will be, Mailman will provide
interfaces for these things and ensure that the application is
written to only ask these questions through the interface. It will
be easy to plug in different backends, so if someone were to write an
LDAP or hybrid backend, Mailman would work with it. This will be
much easier than the current hacks required for Mailman 2.1. The
goal would be to support such plugins through Python eggs, so that
such extensions are easy to install and enable.
Something that I've mentioned before, is the importance of preventing collateral spam. So, I'd like to be able to have my MTA ask Mailman
whether a particular email address is permitted to post to a particular
list, at SMTP time. I'm using Exim, which could call an external python
script, but I'd rather be able to issue an SMTP callout to a running daemon, for efficiency. The callout would be executed after each "RCPT TO".
Yes, you'll have this capability. Really, you could do it now with a
bit of Python coding. I'm currently jonesing for a RESTful interface
to Mailman 3 for controlling it, asking it questions, etc., which of
course the site-administrator would have to enable. The only other
viable alternatives I see are XMLRPC, or the current 'write some
custom Python script' approach.
- -Barry
On Saturday 7 July 2007 18:35, Barry Warsaw wrote:
Mailman 2.1 is (shockingly) four and a half years old, having been initially released on 30-Dec-2002. The last release in the series, 2.1.9 was made almost a year ago. In the meantime, Mark and Tokio have been doing a great job maintaining the 2.1 branch, with several important patches in the tree now that will eventually become 2.1.10. The problem of course is that we can't add any new features to the 2.1 family <wink>, so we should be thinking about a new major release.
These sound like sensible plans and I'm curious about what 2.2 and 3.0 will bring. However, my question is whether we can expect some 2.1.x releases in the short term (like 2.1.10 you mentioned). As you say it will take quite some while for 2.2 to be released, and we'd like to get the fixed bugs in the 2.1.x branch to our users in the meantime.
Regular 2.1.x releases with assorted fixes would be welcome to not scare users away from Mailman while we're waiting for the "big" releases.
thanks, Thijs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 9, 2007, at 10:06 AM, Thijs Kinkhorst wrote:
These sound like sensible plans and I'm curious about what 2.2 and
3.0 will bring. However, my question is whether we can expect some 2.1.x
releases in the short term (like 2.1.10 you mentioned). As you say it will take
quite some while for 2.2 to be released, and we'd like to get the fixed
bugs in the 2.1.x branch to our users in the meantime.Regular 2.1.x releases with assorted fixes would be welcome to not
scare users away from Mailman while we're waiting for the "big" releases.
Agreed. Mark and Tokio will decide when 2.1.10 is ready, and I
suspect that we will have perhaps a few more point releases before
2.2 and 3.0 are out.
I would like the upgrade from 2.1.x to 2.2 to be as easy as 2.1.x to
2.1.x+1. The upgrade to 3.0 will likely require running an 'export'
command in 2.x followed by an 'import' command in 3.0. The really
tricky parts will be resolving conflicts when merging users. I
haven't thought this far ahead, but it may be that there's an
intervening conflict resolution step, or resolution strategies in the
'import' command.
- -Barry
I apologize for the late chiming in here.
I'd like to propose the XMLRPC extension for Mailman 2.2 that has been developed over the last two years. I have in the last couple months updated the patch to 2.1.9 and it's code impact is really quite minimal; it's really quite standalone. And for those looking for ways to interact with the Mailman database from other applications, it provides the necessary interfaces for administration and moderation functions.
Thoughts?
-jag
Barry Warsaw wrote:
Now that we've successfully navigated the switch to Bazaar, it's time
to lay out plans for future Mailman releases. I've talked to several
people about what to do about Mailman's future and I'd like to take
this opportunity to describe my thoughts and get your feedback.
First some background.Mailman 2.1 is (shockingly) four and a half years old, having been
initially released on 30-Dec-2002. The last release in the series,
2.1.9 was made almost a year ago. In the meantime, Mark and Tokio
have been doing a great job maintaining the 2.1 branch, with several
important patches in the tree now that will eventually become
2.1.10. The problem of course is that we can't add any new features
to the 2.1 family <wink>, so we should be thinking about a new major
release.I've been making good progress on the SQAlchemy/Elixir version, which
will finally get rid of pickles and put Mailman on a Real Database
(tm). It's been clear to me for a while that this branch will have a
unified user database. It simply makes no sense to build the
database back-end without once and for all fixing this design
constraint. I've always said that the unified user database will be
in Mailman 3, and thus this branch is indeed called "Mailman 3.0".I've been slowly building things back up from the ground floor. The
basic data model is in pretty good shape and I'm taking a religious
test-driven approach to making things work again. But the branch
still needs a lot of work, and I have no ETA for Mailman 3.0.In the meantime, Andrew Kuchling and others have volunteered to work
on modernizing the Mailman web u/i, and Terri recently started a
thread discussing updates to the archiver. I think it makes sense to
bless these efforts, towards the goal of releasing them in Mailman
2.2. I intend to create an official Mailman 2.2 branch in bzr where
these efforts can land as they mature. My hope of course is that
we'll also be able to use much of this new code for Mailman 3.I'd like to keep the changes for 2.2 focused on the web u/i and
archiver, with a small number of additional features to be
determined. Mailman 2.2 should see no changes to the basic
architecture or 'database'; we'll continue to use pickles by default
for Mailman 2.2. While I won't rule out other new features, I want
to be very picky about those that are accepted for 2.2, and would not
feel bad at all if we rejected or deferred until 3.0 most of those
proposed. Criteria for other 2.2 features must include minimal code
impact with a high degree of reliability and stability.I plan on updating the wiki pages to reflect this thinking, but I
would like to get feedback from y'all about the plan. It would be
awesome if we could see a release of Mailman 2.2 some time in late
2007 or early 2008.Comments, question?
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
-
Arne Schwabe -
Barry Warsaw -
Ian Eiloart -
Joshua 'jag' Ginsberg -
Thijs Kinkhorst