[Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url)

[Christian Tismer]

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
> century.

I am just saying that the changes, which affected my config
unfortunately, were not tested against a machine which would
use them.

Besides that, I have seen some changes to some scripts which were
obviously wrong and made it into the next release.
Example:
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:tismer@appliedbiometrics.com>
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