Package: bugs.debian.org Severity: wishlist This is a summary of a long discussion between Don and me on #debian-boot earlier today [1] on #debian-boot.
The problem is that quite regularly bugs are filed that are html only or text/html and have missing line feeds. This often makes the headers invalid, leading to completely broken initial assignment of bugs, which also means that in a lot of cases the relevant developers never get to see the original report, but only the reassignment by one of the BTS janitors. It also makes the report rather unreadable in general. Examples (but there are many more): - http://bugs.debian.org/457057 - http://bugs.debian.org/464023 There are different possible solutions, each with their own (dis)advantages. They are listed in my personal order of preference. 1) detect and reject the initial report pro: clear; avoids any uncertainties about the further handling of the report; no blame with maintainers for not responding (to something of which he's often completely unaware); places effort with person causing the problem; does not waste scarce project resources (human) on interpreting and replying to unreadable messages con: harsh and leaves user somehat in the cold 2) automatically correct the problem, at least for the Package: header pro: the maintainer will at least get to see the original report; more friendly towards users con: may still leave teh maintainer with an often unreadable report which does not invite anyone taking responsibility (especially a problem in teams); "rewards" the use of completely broken MUAs and services 3) make sure that the maintainer gets to see the original message by changing the way reassigns are handled Although I'm very much in favor of doing this for its own sake (I've advocated this before), I don't think this does anything to address the issue. It still leaves the maintainer with a fundamentally broken BR. Don: it's OK with me if you want to attach the log from our conversation. Cheers, FJP [1] For Don that's probably still true, for me it's actually about 4 hours into tomorrow, but well.
signature.asc
Description: This is a digitally signed message part.
