Hi. On Thu, 2012-10-25 at 21:26 +0900, Osamu Aoki wrote: > But if you read history of bug report including patches, you could have > written a bit kinder tone message. I feel a bit sad to see this message. Well it wasn't meant particularly personally or offensive,... I just think the issue is quite serious.
I see now, that you considered this just to be a documentation problem... IMHO, one needs to look throughout all Debian, to find any places where mboxo is still used. The problem is, that using mboxo itself (even if documented) is IMHO a serious bug, as the format is utterly broken. Especially no user expects that when he stores mail it's being irrecoverably cluttered up (which is what mboxo does). Actually I'd say that most people even don't know that there are different subformats of mbox. > No. This is not news. So not an appropriate place. > Right place should be more like README.Debian or BUGS. Mhh well in principle that's true, but to my experience, NEWS is the only place (apart from release-notes and debconfi dialgues) that is likely read by most people (well at least by those that have apt-listchanges installed). Does Debian expect people to read README.Debian? > > - if possibly in a priority-high dialogue via debconf > This is not right place per policy. Is that forbidden? I used to know several packages that put informative dialogues there (even though not with priority high, I guess). > > If upstream is stupid and doesn't want to fix this, then we really > Please do not call upstream stupid ... especially in public like this. > I think you are bright but this is not very polite. As I already told upstream himself,... I said _if_ (perhaps I should have written "even if")... So when I wrote this, I haven't thought you'd just consider this as a documentation issue. Therefore I wanted to make clear, that even when an upstream would be stupid/not cooperating/etc. ... we (in Debian) should not just lean back. > > really must warn our users on that issue. > > And even if upstream would fix it, we still would need to warn our users > > at least in the NEWS file / release notes... that all their mail from > > previous years is likely corrupted. > mboxo has been always so and have been widely used. I know, and this is actually quite a problem. As I wrote above, most people don't know this... and AFAIU the corruption inherent to this format can't be undone. > mboxrd is technically superior. Yes,... an alternative is mboxcl2... but it has also it's drawbacks. > anyone who stores file in mbox should know there are risks as you > describe. Phew... I mean I wouldn't call myself uneducated ;-) ... and I was really shocked when I learned about this recently. I asked around at my friends, all studied computer scientists and decent sysadmins... noone knew. > I think you are a bit exxagurating severity of trivial part of data > change. Actually most people seem to see it like this. I can't join that opinion however. I mean the change is little, arguably, but a) it can't be undone automatically and b) given, that storing mail is the core functionality of e.g. getmail, it think it's quite severe. That would be the same if your paint program changes all the colours (just a tiny bit) when you save your image. > Let's ask release manager how this should be handled now. Saw your mail :) Thanks for your efforts :) Best wishes, Chris.
smime.p7s
Description: S/MIME cryptographic signature
