Re: forwarding bugs to other packages
On Thu, Oct 21, 2004 at 01:28:41PM +1000, Brian May wrote: Joel == Joel Baker [EMAIL PROTECTED] writes: Joel It would also presumably allow you to add a filter such as Joel don't display any bug with a dependancy on any other Joel still-open bug; thus allowing maintainers to have things Joel automagically show up again once the bug they're waiting Joel on has been resolved. If you do this, different types of dependancies (or relationships) might be desirable. eg: Possibly; depends on how hard it is to do, really, for the benefit. bug x is bug y -- declaration that both bugs are the same, once y is fixed x needs to be rechecked but is most likely fixed. bug x depends bug y -- y must be fixed before work on x can continue. Closing y doesn't mean x is fixed. bug x suggests bug y -- y might be a possible solution to this bug. Other solutions/workarounds may also be possible. Closing y means x is probably fixed but needs testing. If more thought was put into this, I am sure we could come up with something better. Well, that seems like a start, anyway. Really, I'd like some input from someone more familiar with the BTS code before going off into the wild blue yonder. It's possible this has been proposed and discarded before, for good reason, after all... or not. -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `-
Re: forwarding bugs to other packages
Wouter == Wouter Verhelst [EMAIL PROTECTED] writes: Wouter Simple. When merging a bug, you claim that the two bugs Wouter are really the same. They're not just related, nor are Ok, so what we need is a method of saying two bugs are related, but not the same. Colin == Colin Watson [EMAIL PROTECTED] writes: Colin If you like, you can reassign both bugs to foo,bar and Colin merge them. Only if the two bugs are exactly the same. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
Joel == Joel Baker [EMAIL PROTECTED] writes: Joel It strikes me that this problem is actually similar to a Joel couple of others, and all of them could be reasonably Joel resolved by a new concept in the BTS - bug dependancies. Joel All it really says is Some part of this bug depends on some Joel part of bug #XX - maybe you think the segfault is Joel actually from a library and so you have no intention of Joel trying to fix it until the library bug is fixed (at which Joel point, you might well change your Depends entry versioning Joel for the library, etc). Sounds good to me. Joel Or maybe there's a feature request you're happy to add, but Joel need to have another package support first (say, maybe Joel you're adding alternatives to a variety of things, and they Joel all need to update to provide it at roughly the same time, Joel with versioned conflicts, to be happy). Been there, done that ;-). For example, implementing update-alternatives. It must be done in all packages, and isn't really complete until every package is changed. Just because one package Joel It would also presumably allow you to add a filter such as Joel don't display any bug with a dependancy on any other Joel still-open bug; thus allowing maintainers to have things Joel automagically show up again once the bug they're waiting Joel on has been resolved. If you do this, different types of dependancies (or relationships) might be desirable. eg: bug x is bug y -- declaration that both bugs are the same, once y is fixed x needs to be rechecked but is most likely fixed. bug x depends bug y -- y must be fixed before work on x can continue. Closing y doesn't mean x is fixed. bug x suggests bug y -- y might be a possible solution to this bug. Other solutions/workarounds may also be possible. Closing y means x is probably fixed but needs testing. If more thought was put into this, I am sure we could come up with something better. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
On Tue, Oct 19, 2004 at 08:26:23AM +1000, Brian May wrote: Bernd == Bernd Eckenfels [EMAIL PROTECTED] writes: Bernd On Mon, Oct 18, 2004 at 05:54:44PM +1000, Brian May wrote: I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). Bernd So you do not want to reassign them to the correct package? Bernd I dont think thats a good idea (even when i can understand Bernd where are you coming from). Like I said in my previous post, there are times when having 2 separate bug reports is a good idea. e.g. you might think a reported bug in your package is due to a bug in a library, so you reassign the bug report to the library. The library maintainer decides it isn't a bug in the library, and prematurely closes the bug report. Or maybe the library maintainer finds a bug, and fixes it, but it was an unrelated bug. You never get the indication that the bug report has been closed, and the bug submitter gets totally confused and either doesn't follow up (perhaps assuming the problem was fixed), or follows up to the wrong person (as the bug is still assigned to the library). As such you don't get a chance to followup and make sure the bug, initially reported against your package, really gets fixed. Alternatively, when you reassign the bug to the library, the library maintainer gets fed up because he already has 10+ bug reports on the same issue. It strikes me that this problem is actually similar to a couple of others, and all of them could be reasonably resolved by a new concept in the BTS - bug dependancies. All it really says is Some part of this bug depends on some part of bug #XX - maybe you think the segfault is actually from a library and so you have no intention of trying to fix it until the library bug is fixed (at which point, you might well change your Depends entry versioning for the library, etc). Or maybe there's a feature request you're happy to add, but need to have another package support first (say, maybe you're adding alternatives to a variety of things, and they all need to update to provide it at roughly the same time, with versioned conflicts, to be happy). It would also presumably allow you to add a filter such as don't display any bug with a dependancy on any other still-open bug; thus allowing maintainers to have things automagically show up again once the bug they're waiting on has been resolved. Of course, I make no claim that the BTS folks won't want to rip my spleen out for bringing this up, but it does seem like it could be used to resolve a couple of different types of problem. (It also allows yet another way to avoid BTS tennis matches; if the maintainer of the other package doesn't agree that it's the same thing, put in a depends and wait for them to resolve whatever the bona-fide bug in their package is, rather than arguing about it.) -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
forwarding bugs to other packages
Hello, I have a number of bugs reported against my packages which are actually (already reported) bugs in other packages. I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). I want a way to filter out these reports, so when I get a list of outstanding bugs in my packages, I only get to see real bugs in my package. Is there anyway I can do this? I have looked at the list of tags, and not seen anything appropriate. I could mark the bug as forwarded upstream to [EMAIL PROTECTED], where n is the real bug report, but it isn't really upstream... Also a method of automatically finding out when bug n is closed, so I can close my bug report would be nice, too. Is anything like this possible? Thanks. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). How about merging those bugs with the bug reported against the correct package? That'd result in your buggetting automatically closed when the bug is fixed in the other package, it would probably make filtering easier too, and the bug would normally appear on the bug page of your package, so users would notice it and won't report it again and again. HTH, -- Gergely Nagy
Re: forwarding bugs to other packages
On Mon, Oct 18, 2004 at 05:54:44PM +1000, Brian May wrote: I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). So you do not want to reassign them to the correct package? I dont think thats a good idea (even when i can understand where are you coming from). Perhaps we need a read this before submitting bugs against my package function in reportbugs :) Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: forwarding bugs to other packages
On Mon, Oct 18, 2004 at 10:19:18AM +0200, Gergely Nagy wrote: I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). How about merging those bugs with the bug reported against the correct package? That's not possible. You can only merge bugs if /all/ properties (tags, severity, package reported against, ...) are the same. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: forwarding bugs to other packages
Bernd Eckenfels [EMAIL PROTECTED] schrieb: On Mon, Oct 18, 2004 at 05:54:44PM +1000, Brian May wrote: I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). So you do not want to reassign them to the correct package? I dont think thats a good idea (even when i can understand where are you coming from). Perhaps we need a read this before submitting bugs against my package function in reportbugs :) Unless we have that function, I fear we sometimes need to keep a copy of a bug open in the wrong package. E.g. we have a bug which was first reported as #247849, which is reassigned to debconf (and merged with an other one there. After reassigning, we got #257022 and #264982. I'd rather keept them in our package instead of reassigning (and waiting until the next clone comes in against tetex). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: forwarding bugs to other packages
* Wouter Verhelst [EMAIL PROTECTED] [2004-10-18 13:32]: That's not possible. You can only merge bugs if /all/ properties (tags, severity, package reported against, ...) are the same. Just for the record, tags are an exception. They are merged when you merge bugs. -- Martin Michlmayr http://www.cyrius.com/
Re: forwarding bugs to other packages
* Bernd Eckenfels [Mon, 18 Oct 2004 12:01:32 +0200]: Perhaps we need a read this before submitting bugs against my package function in reportbugs :) such functionality exists, via the /usr/share/bug/package/presubj file. see /usr/share/doc/reportbug/README.developers. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Nobody can be exactly like me. Sometimes even I have trouble doing it. -- Tallulah Bankhead
Re: forwarding bugs to other packages
Bernd Eckenfels wrote: Perhaps we need a read this before submitting bugs against my package function in reportbugs :) That already exists: /usr/share/bug/. reportbug galeon provides a reasonable example run.
Re: forwarding bugs to other packages
On Monday 18 October 2004 09.54, Brian May wrote: Hello, I have a number of bugs reported against my packages which are actually (already reported) bugs in other packages. Reading the rest of the thread, I conclude that adding an explanation to the bug and tagging it wontfix is probably the best solution. cheers -- vbi -- Oops pgpYdxrEyBLOv.pgp Description: PGP signature
Re: forwarding bugs to other packages
On Monday 18 October 2004 06:01 am, Bernd Eckenfels wrote: Perhaps we need a read this before submitting bugs against my package function in reportbugs :) I've actually seen some packages do this. For instance, try submitting a bug against mozilla-firefox.. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Oh my god! The entire map is written in GIBBERISH!| | Worse, my friend. It's written in German! -- Fluble | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpanh4N8kafG.pgp Description: PGP signature
Re: forwarding bugs to other packages
Wouter == Wouter Verhelst [EMAIL PROTECTED] writes: Wouter On Mon, Oct 18, 2004 at 10:19:18AM +0200, Gergely Nagy wrote: I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). How about merging those bugs with the bug reported against the correct package? Wouter That's not possible. You can only merge bugs if /all/ Wouter properties (tags, severity, package reported against, ...) Wouter are the same. Why is this? I can open one bug against multiple packages, so I think it should be possible to merge two or more bugs against different packages. Still, I can think of times when merging isn't appropriate. e.g. consider: bug report 1 package A: Program A segfaults. bug report 2 package B: libb segfaults. In which case, the 2 bug reports may highlight different aspects of the same bug; while they are the same bug they are not the same. Bug 1 would list the details of the bug from the users perspective trying to run A, but bug 2 is more likely to have extensive debugging information proving the library is at fault. Also, if I encountered a problem with A segfaulting, I would notice the first title, but I might miss the second title (unless I knew A was linked against libb). When bug report 2 is closed, the maintainer of A may want to double check to make sure that the bug really is fixed in A (maybe bug 2 wasn't the real cause after all), before 1 gets closed. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin * Wouter Verhelst [EMAIL PROTECTED] [2004-10-18 13:32]: That's not possible. You can only merge bugs if /all/ properties (tags, severity, package reported against, ...) are the same. Martin Just for the record, tags are an exception. They are Martin merged when you merge bugs. What happens to the tags if the two reports are split apart again? Are their original values restored, or do they keep their new values? -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
Bernd == Bernd Eckenfels [EMAIL PROTECTED] writes: Bernd On Mon, Oct 18, 2004 at 05:54:44PM +1000, Brian May wrote: I could just close the bug against my package, but this means other people will encounter the same problem and report the bug against my package again (as it isn't always obvious that it isn't the fault of my package). Bernd So you do not want to reassign them to the correct package? Bernd I dont think thats a good idea (even when i can understand Bernd where are you coming from). Like I said in my previous post, there are times when having 2 separate bug reports is a good idea. e.g. you might think a reported bug in your package is due to a bug in a library, so you reassign the bug report to the library. The library maintainer decides it isn't a bug in the library, and prematurely closes the bug report. Or maybe the library maintainer finds a bug, and fixes it, but it was an unrelated bug. You never get the indication that the bug report has been closed, and the bug submitter gets totally confused and either doesn't follow up (perhaps assuming the problem was fixed), or follows up to the wrong person (as the bug is still assigned to the library). As such you don't get a chance to followup and make sure the bug, initially reported against your package, really gets fixed. Alternatively, when you reassign the bug to the library, the library maintainer gets fed up because he already has 10+ bug reports on the same issue. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
Adeodato == Adeodato Simó [EMAIL PROTECTED] writes: Adeodato * Bernd Eckenfels [Mon, 18 Oct 2004 12:01:32 +0200]: Perhaps we need a read this before submitting bugs against my package function in reportbugs :) Adeodato such functionality exists, via the Adeodato /usr/share/bug/package/presubj file. see Adeodato /usr/share/doc/reportbug/README.developers. I really don't see how this is going to help, unless you want to list known bugs in the package. This implies uploading a new copy of the package when bugs in other packages are fixed. It also will only work if you use reportbug. If you are just browsing the BTS via HTTP to find a solution to your problem, you may not find anything. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
Adrian == Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] writes: I have a number of bugs reported against my packages which are actually (already reported) bugs in other packages. Adrian Reading the rest of the thread, I conclude that adding an Adrian explanation to the bug and tagging it wontfix is probably Adrian the best solution. You could be right here. You won't get informed if the bug is closed though, and the wontfix status may imply you don't want to fix the bug. -- Brian May [EMAIL PROTECTED]
Re: forwarding bugs to other packages
On Tue, Oct 19, 2004 at 08:14:25AM +1000, Brian May wrote: Wouter == Wouter Verhelst [EMAIL PROTECTED] writes: Wouter That's not possible. You can only merge bugs if /all/ Wouter properties (tags, severity, package reported against, ...) Wouter are the same. Why is this? Simple. When merging a bug, you claim that the two bugs are really the same. They're not just related, nor are they only similar; they are the same bug -- the problems described in both bug reports result from the same programmer error. Because they are the same bug, they must be equal in the BTS. The same programmer error cannot occur in two packages at the same time, unless they're built from the same source. Hence, the BTS insists that their parameters are the same. I can open one bug against multiple packages, Yes, but in that case the claim is that there is a bug in the communication between, or the integration of, both packages. That's not really the same thing. Usually, when filing bugs against multiple packages is appropriate, the error that was made is one of communication between two programmers. [...no other remarks...] -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: forwarding bugs to other packages
On Tue, Oct 19, 2004 at 08:16:02AM +1000, Brian May wrote: Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin * Wouter Verhelst [EMAIL PROTECTED] [2004-10-18 13:32]: That's not possible. You can only merge bugs if /all/ properties (tags, severity, package reported against, ...) are the same. Martin Just for the record, tags are an exception. They are Martin merged when you merge bugs. What happens to the tags if the two reports are split apart again? Are their original values restored, or do they keep their new values? They keep their new values. -- Colin Watson [EMAIL PROTECTED]
Re: forwarding bugs to other packages
On Tue, Oct 19, 2004 at 08:14:25AM +1000, Brian May wrote: Wouter == Wouter Verhelst [EMAIL PROTECTED] writes: How about merging those bugs with the bug reported against the correct package? Wouter That's not possible. You can only merge bugs if /all/ Wouter properties (tags, severity, package reported against, ...) Wouter are the same. Why is this? I can open one bug against multiple packages, so I think it should be possible to merge two or more bugs against different packages. If you like, you can reassign both bugs to foo,bar and merge them. -- Colin Watson [EMAIL PROTECTED]
