Okay, thanks. If possibly, please submit a SourceForge bug report on this so it doesn't get lost in my inbox.

Just want to add a note about why I've been so quiet on this list lately. You hardcore Pythoneers know that Python 2.0beta1 is slated for release on 5-Sep-2000, so I've been spending all my time on Python issues.

The Python 2.0beta -> Python 2.0 final cycle is very short, so, while I hope to find time to attack outstanding Mailman problems in that timeframe, don't be surprised if I'm jammed up until after Python 2.0 final is released. We've got a mostly congealed deadline of 6-Oct-2000 for that and afterward, I'll be spending most of my time finishing up Mailman 2.0, and hopefully addressing the outstanding design issues for Mailman-the-way-it-should-be.

it's-no-fun-trying-to-get-two-2.0-releases-out-at-once-ly y'rs, -Barry

On 2000.09.13, in <14784.23202.487093.880960@anthem.concentric.net>, "Barry A. Warsaw" <bwarsaw@beopen.com> wrote:

...

...

...

...

...

"DC" == David Champion <dgc@uchicago.edu> writes:

| Looks like line 121 of scripts/driver needs to say
|         from Mailman.Version import VERSION
| instead of
|         from Mailman.mm_cfg import VERSION

DC> I know enough python to club myself in the head, but I think I
DC> hit this one because I had a bug (since resolved) in
DC> Defaults.py.[1] If Defaults.py or mm_cfg.py have a traceback
DC> error, this looks like it will come up.  By importing VERSION
DC> explicitly as below, you at least can get the trace
DC> informationon the _original_ problem.  If it's inherited from
DC> Defaults.py, then you still get this problem.

DC> [1] If you're curious, I modify Defaults.py to have a separate
DC> data area from the mailman installation directory.

Please note that you should never edit Defaults.py. Put all your site configurations in mm_cfg.py, which will override the settings in Defaults.py.

I disagree, but now's not the time to debate that. It's not the issue I was raising, anyway. You said in the patch followup that "the problem stemmed from an error introduced in Defaults.py by the user." Not exactly; changes to Defaults.py illuminated what seemed already to be a problem.

The bug I created caused a traceback report, but that traceback itself was faulty. *That* is what this patch tried to fix.

I don't know whether that makes any difference, though.

-- -D. dgc@uchicago.edu NSIT University of Chicago

At 2:48 AM -0400 9/14/00, Barry A. Warsaw wrote:

I still claim the site admin should never edit Defaults.py. Why do you disagree?

Oh, heck, Barry, what do you know, anyway? It's not like you wrote this system or anything..

chuq (ducking and running)

Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

At 2:04 AM -0500 9/14/00, David Champion wrote:

I think of Defaults.py as the set of defaults for this build of the software, not just a canonical reference of what's settable.

This is a flawed assumption, but given what you're doing and how mailman does things, probably a necessary one.

In reality, what we're starting to talk about is building in multiple levels of configuration -- there's the release configuration, the site configuration, the vhost configuration, list configurations, and at some point, admin and user configurations driven out of the subscriber records.

Oh, yeah. something else mailman needs, although not exactly difficult but not a high priority: a single list living on multiple domains. For instance, I currently have some lists living on plaidworks.com. They'll soon move to hockeyfanz.com. But -- there are existing pointers to the old place, and it'd be nice if I could have them visible in both places for at least some period of time during transitions. That seems to be fairly easy to add (I just don't have time to do it now... sigh)

chuq

Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

CVR> In reality, what we're starting to talk about is building in
CVR> multiple levels of configuration -- there's the release
CVR> configuration, the site configuration, the vhost
CVR> configuration, list configurations, and at some point, admin
CVR> and user configurations driven out of the subscriber records.

Don't forget language/locale configurations! The Mailman I18N effort will be revived too, especially now that Python 2.0 should have the necessary primitive support for i18n.

yup. Which goes back to my idea of completely separating the content issues out of mailman and accessing it through it's own API, so you can say something like "get_message(UNSUB,LISTNAME, SPANISH) and whatever you get back is the the proper piece -- so that all this stuff can be added to mailman without mailman actually having to worry about it.

(I've actually fleshed this out to some level of detail, I just haven't had time to write it down... And to add to the joy, I've just agreed to stand for vice president of the Science Fiction Writers of America, so I may have a new time sink pending sometime next year...)

-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"