Mailman 2.x Roadmap
Barry has been making wonderful progress with Mailman 3.0 and has just announced the second alpha release.
This may leave some of you wondering what's happening with the Mailman 2.x series, so this note is for all interested Mailman users, developers and translators to give an idea of what to expect in Mailman 2.x in the coming months.
Within the next few days, I plan to release Mailman 2.1.12rc1. This release contains several minor bug fixes since 2.1.11 and is updated for compatibility with Python 2.6. It will not work with Python older than 2.4.
In the absence of "show stopping" bugs, the only changes between this and the final 2.1.12 release will be translation updates. I expect to release the final by the end of January.
After January, my focus will be on Mailman 2.2. This branch was originally intended to be an overhaul of Mailman's GUI, but that work is stalled and will be deferred to Mailman 2.3 or 3.0. The focus of Mailman 2.2 will be ongoing maintenance of the 2.x series and several small new features that have not been added in the 2.1 branch because of i18n considerations.
I hope to be able to release a 2.2 beta before the end of March, 2009.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
On Saturday 3 January 2009 20:51, Mark Sapiro wrote:
Within the next few days, I plan to release Mailman 2.1.12rc1. This release contains several minor bug fixes since 2.1.11 and is updated for compatibility with Python 2.6. It will not work with Python older than 2.4.
With regard to bugfixes for the 2.1.x branch, you may be interested in the patches that Debian has made to the mailman package in our distribution. You can find them all here under the '"series" style patches'-header: http://patch-tracking.debian.net/package/mailman/1:2.1.11-8
Of course some are only useful for Debian, some already applied in your branch, but perhaps there are some useful bits there you may want to take for 2.1.12.
cheers, Thijs
On Sun, Jan 4, 2009 at 11:04 PM, Thijs Kinkhorst <thijs@debian.org> wrote:
On Saturday 3 January 2009 20:51, Mark Sapiro wrote:
Within the next few days, I plan to release Mailman 2.1.12rc1. This release contains several minor bug fixes since 2.1.11 and is updated for compatibility with Python 2.6. It will not work with Python older than 2.4.
With regard to bugfixes for the 2.1.x branch, you may be interested in the patches that Debian has made to the mailman package in our distribution. You can find them all here under the '"series" style patches'-header: http://patch-tracking.debian.net/package/mailman/1:2.1.11-8
Of course some are only useful for Debian, some already applied in your branch, but perhaps there are some useful bits there you may want to take for 2.1.12.
In addition to those, there is the Indymedia patch set:
http://lists.indymedia.org/patches.tar.gz (against 2.1.10) http://lists.indymedia.org/patches/ (in use)
Many of those will only be useful for Indymedia (especially the msgid stuff) or only appropriate for the 2.2 branch.
I also went through the output of 'whohas mailman' and found the following distros with patches:
http://trac.macports.org/browser/trunk/dports/mail/mailman/files http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/mailman/files/ http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/mailman/files/ http://packages.opensuse-community.org/listcontents.jsp?checksum=77aa4ba3b6618d256638c4cf28a0305d7062dc7e&distro=openSUSE_110
-- bye, pabs
Paul Wise wrote:
In addition to those, there is the Indymedia patch set:
http://lists.indymedia.org/patches.tar.gz (against 2.1.10) http://lists.indymedia.org/patches/ (in use)
Many of those will only be useful for Indymedia (especially the msgid stuff) or only appropriate for the 2.2 branch.
I also went through the output of 'whohas mailman' and found the following distros with patches:
http://trac.macports.org/browser/trunk/dports/mail/mailman/files http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/mailman/files/ http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/mailman/files/ http://packages.opensuse-community.org/listcontents.jsp?checksum=77aa4ba3b6618d256638c4cf28a0305d7062dc7e&distro=openSUSE_110
Please don't start (or extend) a list of downstream things to look at in the week before a release. First of all, I'm just compulsive enough to actually look, but even so, the most likely result is I'll be overwhelmed, defer everything and then forget about it.
If downstream patches are of general applicability or address bugs in the upstream distribution, they should be reported in the upstream tracker (currently <https://bugs.launchpad.net/mailman>).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, Jan 6, 2009 at 1:09 AM, Mark Sapiro <mark@msapiro.net> wrote:
Please don't start (or extend) a list of downstream things to look at in the week before a release. First of all, I'm just compulsive enough to actually look, but even so, the most likely result is I'll be overwhelmed, defer everything and then forget about it.
If downstream patches are of general applicability or address bugs in the upstream distribution, they should be reported in the upstream tracker (currently <https://bugs.launchpad.net/mailman>).
My apologies. I'll try and find some time to post bugs and feature requests for mm3, perhaps during LCA if not before then.
-- bye, pabs
On Monday 5 January 2009 17:09, Mark Sapiro wrote:
Please don't start (or extend) a list of downstream things to look at in the week before a release. First of all, I'm just compulsive enough to actually look, but even so, the most likely result is I'll be overwhelmed, defer everything and then forget about it.
I have on behalf of Debian a while ago reported a number of our patches to the SF.net tracker, which have not seen any response yet. It's not that we're not willing to contribute patches back, but the previous approach of reporting them to the patch tracker hasn't been fruitful. I have also sent selected patches to the development list in the past with the same result. So I guessed I'd try something different instead.
If downstream patches are of general applicability or address bugs in the upstream distribution, they should be reported in the upstream tracker (currently <https://bugs.launchpad.net/mailman>).
Do I understand it correctly that I should resubmit the patches to this new tracker?
We're quite willing to help you get useful patches integrated, but our time is also limited so I'm looking for the way that is most effective for both of us.
cheers, Thijs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 5, 2009, at 1:19 PM, Thijs Kinkhorst wrote:
On Monday 5 January 2009 17:09, Mark Sapiro wrote:
Please don't start (or extend) a list of downstream things to look at in the week before a release. First of all, I'm just compulsive
enough to actually look, but even so, the most likely result is I'll be overwhelmed, defer everything and then forget about it.I have on behalf of Debian a while ago reported a number of our
patches to the SF.net tracker, which have not seen any response yet. It's not that
we're not willing to contribute patches back, but the previous approach of
reporting them to the patch tracker hasn't been fruitful. I have also sent
selected patches to the development list in the past with the same result. So I guessed I'd try something different instead.If downstream patches are of general applicability or address bugs in the upstream distribution, they should be reported in the upstream tracker (currently <https://bugs.launchpad.net/mailman>).
Do I understand it correctly that I should resubmit the patches to
this new tracker?We're quite willing to help you get useful patches integrated, but
our time is also limited so I'm looking for the way that is most effective for
both of us.
I'll let Mark determine what works best for him an MM2.x, but a couple
of comments: first, the SF tracker issues /should/ have been migrated
to Launchpad. If not, it'll be quicker to resubmit them.
Second, I think in general if you can push bug fix branches to
Launchpad and link them to the bug, they will be much easier to review
and merge into the official branches. Patches in a tracker are more
difficult to use, but probably easier to generate. You could also try
'bzr send' to create a bundle, which is somewhere between a branch and
a patch.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkliWm0ACgkQ2YZpQepbvXEzmQCdH7L8ir2kWqcgQnpWwZuj5/Yj Za0AnR80n/z/z1ym/3kYSC1weFvaKIXP =3AHS -----END PGP SIGNATURE-----
Thijs Kinkhorst wrote:
On Monday 5 January 2009 17:09, Mark Sapiro wrote:
Please don't start (or extend) a list of downstream things to look at in the week before a release. First of all, I'm just compulsive enough to actually look, but even so, the most likely result is I'll be overwhelmed, defer everything and then forget about it.
I have on behalf of Debian a while ago reported a number of our patches to the SF.net tracker, which have not seen any response yet. It's not that we're not willing to contribute patches back, but the previous approach of reporting them to the patch tracker hasn't been fruitful. I have also sent selected patches to the development list in the past with the same result. So I guessed I'd try something different instead.
Of the 32 patches under the '"series" style patches'-header: at http://patch-tracking.debian.net/package/mailman/1:2.1.11-8, two of them carry the note "Submitted upstream" with a SF tracker URL and one notes "Applied upstream"
Of the other 29, my first glance indicates at least four of them are Debian specific, and one is to an unmaintained "contrib" module.
Many of the remaining 24 are like <http://patch-tracking.debian.net/patch/series/view/mailman/1:2.1.11-8/00_stolen_from_HEAD.patch> which carries the note: "Handle empty queue files." I see what this patch does, but I am unable to see why it is necessary. If it were reported in a tracker (I assume it's in a Debian tracker somewhere, but why should I have to search for it?), at least I'd have some information about symptoms and causes that would enable me to evaluate it.
(and at the moment, your entire patch tracking system seems to be not working since all the URLs which I recorded yesterday throw Python exceptions at me today and the link you provided says "There was an error processing ur request can't find any package named or containing 'mailman'")
If downstream patches are of general applicability or address bugs in the upstream distribution, they should be reported in the upstream tracker (currently <https://bugs.launchpad.net/mailman>).
Do I understand it correctly that I should resubmit the patches to this new tracker?
No. All the RFEs and bug reports were migrated from SF to the LP tracker. Due to a processing glitch, patches more recent than 2002-04-03 were not migrated, but this is an issue we expect to fix. See <https://bugs.launchpad.net/mailman/+bug/294223> for more on this migration glitch.
Again, you don't have to resubmit anything from the SF tracker.
We're quite willing to help you get useful patches integrated, but our time is also limited so I'm looking for the way that is most effective for both of us.
I appreciate that, and I am well aware that there is stuff in the tracker that has been sitting unattended for a long while. I am trying to attend to new tracker items as they arrive (at least those that address bugs) and hopefully the old ones will get looked at too.
No system is perfect, but in general, the upstream tracker is the best place. At least things can be found there, whereas things buried in mailboxes or the archives of mailing lists are much more likely to be overlooked.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[Trimmed CC to just -developers]
On Jan 3, 2009, at 2:51 PM, Mark Sapiro wrote:
Barry has been making wonderful progress with Mailman 3.0 and has just announced the second alpha release.
This may leave some of you wondering what's happening with the Mailman 2.x series, so this note is for all interested Mailman users, developers and translators to give an idea of what to expect in Mailman 2.x in the coming months.
Within the next few days, I plan to release Mailman 2.1.12rc1. This release contains several minor bug fixes since 2.1.11 and is updated for compatibility with Python 2.6. It will not work with Python older than 2.4.
In the absence of "show stopping" bugs, the only changes between this and the final 2.1.12 release will be translation updates. I expect to release the final by the end of January.
After January, my focus will be on Mailman 2.2. This branch was originally intended to be an overhaul of Mailman's GUI, but that work is stalled and will be deferred to Mailman 2.3 or 3.0. The focus of Mailman 2.2 will be ongoing maintenance of the 2.x series and several small new features that have not been added in the 2.1 branch because of i18n considerations.
I hope to be able to release a 2.2 beta before the end of March, 2009.
Mark, thanks for publishing this roadmap. It seems right on target to
me, with one comment. I really hope that there will not be a Mailman
2.3. I agree we'd hoped that 2.2 would include an updated web ui, but
if that won't happen in 2.2, I'd really like to see that effort put
into 3.0. I agree that there are plenty of other good things that can
go into the 2.2 series to make it very much worthwhile, but after that
I think we should concentrate on 3.0, where the backend storage and
other architectural improvements will really pay off.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkliOToACgkQ2YZpQepbvXG0AACfZcILwdppJDimq8TzRxVfRTxp gFoAoKL2t43LnxawxFIyqaWwGOLWymui =1FuB -----END PGP SIGNATURE-----
I am happy to announce the first release candidate of Mailman 2.1.12.
Mailman 2.1.12 is a minor bug fix and Python 2.6 compatibility release.
The minimum Python for this release is Python 2.4 and it is compatible with Python through 2.6. The previous Mailman releases are not compatible with Python 2.6.
See the release notes at <https://sourceforge.net/project/shownotes.php?release_id=653108&group_id=103> for more details.
Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites.
For more information, including download links, please see:
http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman
Note to translators:
The mailman.pot is up to date in this release and has been merged with the individual message catalogs. If possible, please review your translations and submit any changes before the end of January.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
I am happy to announce the first release candidate of Mailman 2.1.12.
Mailman 2.1.12 is a minor bug fix and Python 2.6 compatibility release.
The minimum Python for this release is Python 2.4 and it is compatible with Python through 2.6. The previous Mailman releases are not compatible with Python 2.6.
I have discovered a compatibility issue between Mailman 2.1.12rc1 and Python 2.4. As a result of the Python 2.6 compatibility changes, we no longer install the email 2.5.8 package in Mailman's pythonlib if Python's email version is greater. This creates a problem when Python's email is 3.0.1 which is the Python 2.4 package. There is no problem with the email 4.0.x packages in Python 2.5+. The following patch to Scrubber.py works around the incompatibility and will be included in subsequent 2.1.12 releases. === modified file 'Mailman/Handlers/Scrubber.py' --- Mailman/Handlers/Scrubber.py 2008-12-01 04:30:43 +0000 +++ Mailman/Handlers/Scrubber.py 2009-01-12 17:45:14 +0000 @@ -1,4 +1,4 @@ -# Copyright (C) 2001-2008 by the Free Software Foundation, Inc. +# Copyright (C) 2001-2009 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -167,6 +167,9 @@ # message by a text (scrubbing). del msg['content-type'] del msg['content-transfer-encoding'] + if isinstance(charset, unicode): + # email 3.0.1 (python 2.4) doesn't like unicode + charset = charset.encode('us-ascii') msg.set_payload(text, charset) -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Barry Warsaw -
Mark Sapiro -
Paul Wise -
Thijs Kinkhorst