[Pkg-mailman-hackers] Bug#349957: non-ascii bytes cause shunting of some replied cmd messages (attached)

[Lionel Elie Mamane]

On Sun, Jan 29, 2006 at 06:57:58PM +0100, Vlada Macek wrote:
> Lionel Elie Mamane wrote:
>> On Thu, Jan 26, 2006 at 09:34:36AM +0100, Vlada Macek wrote:

>>> Shunted message (displayed by show_qfiles) is attached. It's a
>>> usual confirmation message replied by the user. It's localized to
>>> Czech (l10n from the package unchanged).

>> I can't reproduce this with 2.1.6. I subscribed a user in Czech,
>> quoting the whole confirmation mail in the reply, it works. I tried
>> both sending the reply by UTF-8 and ISO-8859-2.

> The bug was filed against the different package mailman version than
> the one you're using for reproduction tests!

Yes, I'm testing against the version currently in sid, the Debian
"unstable" development branch, and in the beta version of "etch", the
next Debian release. If we can confirm that this bug is corrected in
the version in sid, I'm supposed to close the bug.

> Therefore I think you should not mark it as unreproducible.

Alternatively, I can close it under presumption that it is fixed in
the newer version currently in the development branch of Debian.

Also, don't take the tags too much at heart. There are currently more
than 100 bugs filed against the mailman package, some very old, some
newer. The "unreproducible" tag is a way for me to see which ones I
have already looked at and couldn't reproduce, so that next time I
work on Mailman-in-Debian I can immediately try working on bugs I
haven't seen yet, rather than pore through the dozen I have already
seen and spend hours doing the same things I already did.

> As a user I expect fixing the package that is in my server's Sarge
> distribution, which stays on version 2.1.5-8sarge1 currently.

> Or is there something I do not know? IMHO the packages in current
> Debian Stable should be kept free of known bugs, maybe by
> backporting fixes from newer upstream releases.

I can't say I disagree that trying to keep the latest "stable" branch
as bug-free as possible would be a laudable / desirable goal, but that
is not the current Debian procedures. The way Debian, and most
GNU/Linux distributions, works is:

 - At some point in time, a release is made. In our case, Debian 3.1
   "sarge" in the middle of 2005.

 - Nothing at all is changed in sarge, bugs there stay there, except
   for security updates and really critical bugs.

 - In the meantime, a new release is being prepared, in our case etch
   (which will be numbered Debian 3.2 or maybe 4.0). Non-critical /
   security bugs get corrected in the development cycle of this new
   release.

See http://www.debian.org/releases/ .

You can try to convince Debian to change its way of working, but if
you go this route, good luck. Won't be easy. (The right contact is
debian-project at lists.debian.org.)

> Users are not generally going to upgrade some package ad-hoc from
> other sources, unless it's not some parallel and well known APT
> repository, such as the one for newer releases of PostgreSQL.

I have no idea which one "for newer releases of PostgreSQL" you are
talking about, but if you consider it more well-known than Debian
_itself_, well, we live on another planet.

I'm not saying that running a mixed stable / testing Debian is
necessarily a good idea, but if you want non-criticl/security bugs
corrected before the new release your choices currently are:

 - Run a mixed stable / testing Debian and take the packages that are
   too buggy in stable from testing.

 - Backport the packages from testing yourself.

 - Convince someone at http://backport.org/ to do that.

 - Magic

That is suboptimal, but out of my control. Sorry for that.

-- 
Lionel