[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Thoughts about bts reassign

  Hello all,

  I've recently came up with some problems with the way reassign is
currently used: I filed a bug against Qt4 that had (serious) problems on
HPPA, making several packages FTBS (#435832). It turned out, as I should
have guessed, that this problems had already been reported in bug
#433768, but had turned out to be a kernel bug. Of course, when I
reported the bug to Qt4, I checked the open bug list for Qt4, but I
didn't bother to check for bugs in Qt4's dependencies and kernel and
dpkg and build-essentials and... what else ? I would be very surprised
if anyone did, actually (and I wouldn't have found the problem, as it
was retitled, with no hint of Qt4 left in the title).

  The outcome was that I lost time filing the bug report, and one of
Qt4's maintainer lost time answering. And it's not the first time. So
here is what I propose:

  When a bug filed against a package turns out to be a bug in one of the
dependencies (including implicit ones, such as the kernel and so on...),
instead of simply reassigning the bug to the faulty package, which makes
it disappear from the one that *appears* to be faulty, one should first
clone it, then reassign, and mark the original one as blocked by the
reassigned bug, something like:

clone 12345 -1
reassign -1 foo
block 12345 by -1

 This way, the bug stays open for anyone to see it, and it is linked to
the appropriate discussions in the appropriate package (nice links in
the BTS).

  What do you think about that ? This is just few more lines to



Vincent Fourmond, Debian Developer
-- pretty boring signature, isn't it ?

Reply to: