On Tue, Oct 19, 2004 at 08:26:23AM +1000, Brian May wrote:
> >>>>> "Bernd" == Bernd Eckenfels <lists@lina.inka.de> 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
#XXXXXX" - 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 <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature