Christoph Anton Mitterer wrote: > I wouldn't see why it shouldn't work like this. The fix for the original > problem has issues, and it doesn't make sense to open a new bug for > every issue/subissue/etc. a patch for an original problem introduces.
Sure it does. Now if the package hadn't been uploaded with the fix yet, that would be a different story. In that case, the report would let the maintainer know: "Don't apply this patch unless you are willing to accept the regression I am reporting". But the thing is, after a patch is applied, that particular effect of the feedback is useless. Suppose the bug were "New upstream version; please package". Then before the upload, it's definitely useful to say "One complication of this upgrade is that it will introduce the following regressions", right? And on the other hand after the upload it is not useful to have all bugs in the new version collected in one bug report, is it? They are separate bugs. That imposes a huge burden on the maintainer or whoever is triaging bugs to figure out when each sub-bug is fixed and the bug can be closed, which is what a BTS was supposed to help with in the first place. So please, please, don't reopen a bug to say "Yes, that bug is fixed, but I have another bug". That makes a maintainer's life harder. I'm serious about this. It's an easy mistake to make because in some *other* projects, an existing bug report or thread can be one of the only ways to find an area expert to actually fix something. But here, all BTS mail for a given package goes to the same people, so that really isn't worth it. > Anyway... I guess you know about the issue now =) Yeah, thanks for reporting it. See http://bugs.debian.org/718411 if you'd like to test patches. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
