[Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url)
Fri, 05 Mar 1999 20:45:18 +0100
Harald Meland wrote:
> [Christian Tismer]
> > Harald Meland wrote:
> > >
> > > [Christian Tismer]
> > >
> > > > Hi Barry et al,
> > > >
> > > > I found it - Mailman 1.0b9 has a bug in admin.py .
> > >
> > > Which was fixed _days_ ago in CVS :-)
> > That's great.
> > An average user will step into this trap, since 1.0b9 is the
> > current version. If one always has to check CVS, it makes
> > no sense to publish the zip file at all.
> On the contrary. Releasing betas are _part of_ testing new software.
> Please understand that I'm not saying that I don't appreciate you
> tracking down bugs in Mailman betas -- because I do, really -- but I
> thought it appropriate to respond and say that you could get a better
> fix for your problem from CVS.
I had been using 1.0b7 with success. 1.0b9 introduced a bug
which caused me some trouble, and I wasn't sure where to look:
Did it depend of the slightly different machine, the older Python
version, or mailman?
> > I have to say: 10.b9 was published without proper testing.
> That depends on what you mean by "proper testing". If "proper
> testing" means compiling with all available of the hordes of different
> compilers available on lots and lots of OSes with all combinations of
> "configure" options, and then doing test runs of all parts of Mailman
> with all combinations of web servers, MTAs, Python releases, and
> whatnot, there is _no way_ we will get 1.0 out before the end of the
I am just saying that the changes, which affected my config
unfortunately, were not tested against a machine which would
Besides that, I have seen some changes to some scripts which were
obviously wrong and made it into the next release.
A number of scripts have this path hack (bin/newlist for instance),
and for an older Python 1.5, a try..execpt for getpass was
introduced. Nice idea, but doing this before the "import path"
makes no sense, since Mailman.pythonlib isn't available
before that import.
I think, changes like this make it into the dist too quickly.
Polite speaking is "without proper testing", my company
would yell "thoughtless" at me. :c)
> The core developers _do_ typically check that changes they make appear
> to work right before they check them in -- but occasionally a bug
> slips through.
Well, you say that bug was fixed, see CVS. This means, someone fixed
a bug, put it into CVS, and knew that this bug is in the b9 zip
file, but... did I miss something, or was there a note on the
download page that one might need a patch to get it running?
I didn't want to do testing, but get the latest "stable" version
and assumed that was 1.0b9 . Instead, I spent hours of figuring
out known things, although I was in trouble (had just lost my
old installation and needed a new one ASAP for customers).
> > Anyway, the "/mailman/anything" strings are a little spread
> > around in the sources. In my opinion, it would be safer to
> > keep them in a central place (Defaults.py maybe) and just
> > use references.
> If you have a closer look at the places where /mailman/foobar are
> "spread around", I think you will see that they are usually fallbacks
> that are only used when the appropriate ways of getting at stuff
> doesn't work -- in particular, see the mm_cfg.py variables
> `DEFAULT_URL' and `PRIVATE_ARCHIVE_URL'.
Right, there are just a few places. Anyway I think it would be
cleaner to remove every repetition of a fallback, default or
whatever into one central place. This was not meant as crisicism,
just a hint. If, for instance, the "/mailman/admin" etc.
fallbacks were in one place, a typo from future changes would
either not occour, or show up in a more obvious way.
Be assured, I like Mailman and used it from the first days.
I'm also telling everybody to use it.
At the same time, whenever I want to install it, I get into
some trouble. Usually I can help myself, but what about other
users who just want to follow the instructions and run it?
I think it would be better for MM's public acceptance if there
was always a version known to be used in many installations.
It would not have all new features, but also not the new bugs.
In other words: If the latest beta needed a bug fix, why
don't we mark it as problematic and go back to, say, 1.0b7?
cheers - chris
Christian Tismer :^) <mailto:firstname.lastname@example.org>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home