>>>>> "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 #XXXXXX" - 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]>
