Hi Barry,

Sorry my response is slow :-)

Barry Warsaw wrote:

On Thu, 2004-11-25 at 08:10, Tokio Kikuchi wrote:

...

Since I took charge of CVS committer this September, I belive we could fix number of bugs, merged a few new small-but-nice features, and the code became fairly stable. And, I write 'fixed in CVS' many times answering bug reports these days. Although I have some new features to be added in mind in a longer time scale, I think it is time to take the schedule of new release into consideration. I would like you the developers to download the current source from the CVS (Release_2_1-maint) and test on your testing/working sites before Barry can arrange the time schedule of releasing 2.1.6.

I'd love to see a 2.1.6 release "soon-ish". I will have some time near Christmas to work toward this (testing, docs, spinning tarballs, updating web sites, etc.). It would be nice if we could get 2.1.6 out before the first of the year. Do you think that's feasible?

It's good to hear this. I think we have enough time to fix a few more tiny bugs and announce the translators for updating their languages.

AS for longer term, bigger new features, it probably makes more sense to start that work on the CVS trunk, targeting a Mailman 2.2 release. Of course, merging the 2.1 branch back to the trunk is going to be a "fun" job.

Yeah, I think I can contribute 2.2 while you are at 3.0. Looking back the design notes, we have already some of 2.2 features in 2.1.6. http://zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanTwoDotTwo

May be we can go forward to requirement of Python 2.4 because CJK codecs are integreted there.

-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

On 12/1/2004 6:05, "Barry Warsaw" <barry@python.org> wrote:

I have no problems requiring Python 2.4 for Mailman 2.2, although I would like to get some feedback from the community before we decide for sure. I wouldn't be opposed to requiring at least Python 2.3, but I definitely think we should drop support for earlier Pythons since nothing earlier than 2.3 is being maintained any more.

The Debian part of the community in particular (of which I am not part). I wonder when Python 2.4 will wander into a Debian release.

Perhaps a query on the -users list about requiring Python 2.4 with Mailman 2.2 would produce a solid reason not to.

--John

On Wed, 2004-12-01 at 09:05, Barry Warsaw wrote:

...

May be we can go forward to requirement of Python 2.4 because CJK codecs are integreted there.

I have no problems requiring Python 2.4 for Mailman 2.2, although I would like to get some feedback from the community before we decide for sure.

Red Hat is currently shipping 2.3 in FC2 and FC3. 2.4 won't show up till FC4 which is at least 6 months out. RHEL3 is still shipping with 2.2. RHEL4, which has not yet shipped will have 2.3.

Python 2.3 is going to be installed version of python on Red Hat systems for a while and 2.2 is also common.

I have a suggestion. My understanding is that python 2.4 is desired because the CJK codecs are part of the official python distribution in 2.4. Up to this point mailman installed its own CJK codecs. The proper course of action in my view would be to continue to ship mailman's private copy of the codecs, add a check to "configure" to test for 2.4, if its available use the python version, if not fallback to the previous private method. Sound like a plan?

John Dennis <jdennis@redhat.com>

At 10:47 AM +0000 2004-12-02, Ian Eiloart wrote:

Now, I know someone is going to point out that Apple provide a much hacked version of Mailman - but that's a red herring. I'm referring to people who put vanilla mailman on top of MacOSX - as we plan to do.

If you're going to put vanilla Mailman on top of MacOS X, then 

you could also install Python 2.4 as well.

-- Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

SAGE member since 1995. See <http://www.sage.org/> for more info.

On Fri, 03 Dec 2004 10:36:55 +0900, Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp> wrote:

And also, mailman 2.2 will no be out before next summer. I expect many venders are including Python 2.4 by that time.

As a perhaps extraneous data point supporting this, the FreeBSD lang/python port was bumped from 2.3.4 to 2.4 on Dec 1st (and lo, there was much updating). So any future versions of FreeBSD will have Python 2.4 (or newer) -- FreeBSD 4.11 is aimed for late January 2005, 5.4 will be sometime later in 2005.

Bryan

Stephen J. Turnbull wrote:

(1) Apple already has a couple of "multi-version" applications standard (in particular, GCC, see the gcc_select utility)

gcc_select is completely broken, and doesn't work. It assumes that the only 3.x is 3.1 and fails even at what it claims to do. I have tried and failed to fix the script, eventually doing all (I hope) the appropriate re-linking by hand.

Both Fink and DarwinPorts have their issues, but so far Python isn't one of them.

I definitely agree with you on Fink (doesn't work at all right now because of gcc issue above, and it always had problems with various X implementations, but when it does work it's pretty nice), and only learned about DarwinPorts just now, so thank you!

So it may not be all that difficult for admins of Apple boxes to work around this.

Oh, yeah, back to the topic. Guess I don't have anything to add except to say that requiring all these bolt-on tools in order to install mailman is a bit harsh for non-admins...

-Dale

Brad Knowles wrote:

So, every package written in Perl should include a complete Perl implementation of its very own?

You have misunderstood me. I'm not talking about the languages, I'm talking about fink and darwinPorts. If the only clean way to get multiple language versions to play well together is to use them, then we're basically saying to anyone that wants to install mailman should install those first, and while they're great for unix-geeks like most of us on this list, they're quite heavy tools for someone that just wants a mailing list manager.

-Dale

...

...

...

...

"BAW" == Barry Warsaw <barry@python.org> writes:

BAW> On Tue, 2004-11-30 at 20:07, Tokio Kikuchi wrote:

>> May be we can go forward to requirement of Python 2.4 because
>> CJK codecs are integreted there.

BAW> I have no problems requiring Python 2.4 for Mailman 2.2,
BAW> although I would like to get some feedback from the community
BAW> before we decide for sure.

I'm not in favor of bumping the Python requirement for Mailman to greater than 2.3 any time soon. If you really need something in 2.4 to robustly fix a bug or provide new features, that's one thing. And if you could get rid of crocky homebrew infrastructure in favor of shiny new well-defined Python APIs, that's another. (Eg, I think the new Mailman3 architecture, based on Twisted, is just wickedly cool.)

But at one point my Debian system _insisted_ on _four_ different versions of Python (1.5, 2.1, 2.2, and 2.3) being installed (1.5 is now gone, and I think 2.1 can finally be dispensed with), because of various prerequisites stated by different packages. Besides that, at various points at least two versions of Perl, and two versions of Ruby (and I didn't know I had any Ruby-requiring applications installed!), two versions of autoconf, three versions of automake, ... you get the drift. Pretty yucky. And it's shameful to be outdone by Perl!!

In the case in point, the reason explicitly advanced for moving to 2.4 is that it includes the CJK codecs. That is, there's a bug that someone doesn't feel like addressing properly, so you're going to cover it up. This just ain't right.

IMO, this particular bug goes a lot deeper than the tracebacks in #974290 and #926034, inter alia. I'm currently tracing another bug where Cc contents are being trashed, probably in AvoidDuplicates, but there's similar, redundant (?) code in CookHeaders. This whole notion of cooking headers is pretty bogus, in my opinion, and the reason that unknown coding systems crash the runners is also bogus: Mailman in many places assumes that the headers will be readable and proceeds to try to read them (ie, translate to Unicode). In some places it even assumes that the header will be in ASCII! My host's error log is full of entries like

Dec 02 17:25:57 2004 (17826) SHUNTING: 1102026356.809988+4f78036cea165d4e72f6ed3 5943a75961cc7da67 Dec 02 17:33:36 2004 (17826) Uncaught runner exception: 'ascii' codec can't decode byte 0xa4 in position 0: ordinal not in range(128) Dec 02 17:33:36 2004 (17826) Traceback (most recent call last): [OMITTED, but FYI it's make_headers() -> h.append() again] UnicodeDecodeError: 'ascii' codec can't decode byte 0xa4 in position 0: ordinal not in range(128)

NB: this one can't be worked around by adding the CJK codecs. :-/

What to do? Well, let's get radical and actually think about what's going on here from the beginning. Mailman is really a special-purpose MTA. So ...

Offhand, I can't think of any reason why I would _ever_ want Mailman to _change_ an _existing_ header. I understand that there are a large number of uneducated perverts with asthmatic MUAs who want Reply-To munging out there, and that there are broken MUAs that produce broken (ie, redundant) Cc headers, and the like. I can almost sympathize with Subject munging (although the List-ID header makes list names redundant). But I don't need any of that, and it's really annoying that Mailman does some of those things behind my back, especially when the implementation is buggy.

Similarly, the only reason I can think of why _I_ would want Mailman to _read_ any headers is to parse out an address (eg, for dupe suppression), to handle the Approved header, and to handle admin requests. Well, if RFC 2822 parsing (which is hard enough as it is) isn't good enough, that's not Mailman's problem---it's going to baffle the snot out of Sendmail, too. So I see no _need_ for conversion of any headers to Unicode by default! (I think of ToArchive as calling a separate application, not as part of Mailman.)

I conclude that the default pipeline should Just Say No to I18N in the headers. "We don' need no steenkin' Unicode here." (I18N for the UI and the message headers/footers is a completely different issue, of course.)

Optional Handlers? Of course.

Do you want CC coalescing? Add a Handler to the pipeline. (Note that this can be implemented simply by s/^cc:/, /i and appending the result to the previous Cc header, then folding as necessary; no need even to parse out the content, let alone translate it to Unicode.)

Do you want Reply-To munging? Ditto.

Do you want to sanity check addresses as a service to posters? Add a Handler. Still no need for I18N, though.

Do you want Subject munging? OK, ya got me. Here we do want I18N. But you can still do it with a separate Handler, and you can make it plain that Here Be Dragons by calling it MungeSubject_I18N or even MungeSubject_TimeBomb or MungeSubject_MUA (where the last is intended to indicate that Mailman has gone well beyond its MTA Buddha-nature and become entangled in dealing with the illusions of Samsara).

The only real implementation problems I can see are if the email module goes out of its way to parse headers rather than simply storing contents until they are requested, and that the Mailman admin UI currently doesn't provide for munging the list pipeline. Dealing with the former could be hard, but the latter could be handled for 2.1.6/2.2 by making Handlers that simply return successfully without doing any processing if they are disabled. Enabling/disabling to be done via list-specific and mm_cfg variables.

For the future (Mailman3?), one could use a precedence naming scheme (to make sorting the Handlers directory easy) and a checkbox list for basic configuration:

Mailman Handler Pipeline:

[ ] 00_SpamDetect [ ] 01_Approve [ ] 05_Replybot [ ] 10_Moderate [ ] 15_Hold [ ] 20_MimeDel [ ] 25_Emergency [ ] 30_Tagger [ ] 45_CalcRecips [ ] 60_AvoidDuplicates [ ] 70_Cleanse [ ] 75_CookHeaders [ ] 80_ToDigest [ ] 85_ToArchive [ ] 90_ToUsenet [ ] 95_AfterDelivery [ ] 98_Acknowledge [ ] 99_ToOutgoing

(Of course one would suppress the numbering and include docstrings in the web UI, I'm just using this to indicate the idea.) Alternatively, there could be a pipeline_default_order list, which would have _all_ known (standard) Handlers in it, copy that to the pipeline_default and delete the Handlers that are disabled by default.

You'd still have to use bin/withlist to change the order, but since order is often significant, that's probably a Feature, not a Bug.

I'd volunteer to implement a prototype, at least, but I can't do it on the schedule proposed for 2.1.6, sorry. (Note that I don't even know how broken the email module is in this respect yet. :( )

I will get around to submitting bug reports on the issues mentioned above, maybe top of next week?

-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.