Re: the right bug severity in case of data corruption
On Sat, 24 Nov 2012, Christoph Anton Mitterer wrote:
> This however leads to irrecoverable data corruption, as the partial
> quoting of so called From_ lines cannot be undone anymore.
> An easy solution for that dilemma is known for years, namely the other
> mbox formats (either mboxrd, mboxcl or mboxcl2), of which mboxrd is
> typically the one which fits best the needs for staying backwards
> compatible.
...
> No first I've had reported these corruptions at the different upstreams
> (and apart from KMail and mutt...all the major players I've tested, e.g.
> Thunderbird, Evolution, getmail, postfix, were affected).
...
> Apart from the getmail upstream all reacted rather stubborn and without
> much insight,... bringing up obscure "arguments" like "this corruption
> has always been the case historically, therefore it's ok".
At least for postfix, I'd expect them to accept a patch for local(8) to
not quote From lines as a config option, with the default being to keep
the current behaviour (i.e. quote them).
> Well we, as Debian, can't of course force upstreams to fix their crap,
> but IMHO neither should we let our users at risk for silent data
> corruption.
>
> So I've opened bugs at the BTS, too, with severities critical
Look, if it were severity critical, given how long this situation stands,
we'd not have this thread and nobody would be doing this. It is severity
important or normal, I'd say.
In postfix' case, it is documented like all heck, for example (see local(8)
manpage), and it can trivially be configured to use something else to
deliver mail to mbox files (such as procmail, etc).
> So,... bringing this up here at d-d, as I think it would be good for
> Debian to have a well thought position in how to handle this family of
> corruption bugs...
We [Debian] could deprecate anything that uses mboxo (mbox old) format as
the native/preferred storage format, and configure our stuff where possible
to never use mboxo by default. That's about it. But first, you need to get
support for better mbox formats on the important stuff.
We [users/developers] can write patches to teach important software to use
something less retarded than mboxo by default, and pester upstream to take
them. Just complaining about it obviously won't help, since people don't
see it as a problem at all. You need to do _all_ the leg work, write the
new functionality, and test the heck out of it before you can really expect
upstream to accept the change.
> If not, than the majority opinion might perhaps even convince the
> maintainers to handle this with some higher severity :)
That's not how it works. Someone needs to come up with *well tested*
patches for everything worth fixing. THEN you can ask for some sort of
Debian-wide pressure to get rid of mboxo outside of extra/old-libs...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: