Handling of "partial fixes" and bug numbers
martitzam at gmail.com
Mon Jun 22 22:51:11 BST 2009
On Mon, Jun 22, 2009 at 8:59 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:
> There are other options, though.
> 1) Introduce a new bug report, that says we hold > 1x the size of a file
> when committing. And then mark that as related to 109114, but then mark
> the new bug as Fix Released.
> 2) Close the existing bug, and then re-open it with the fact that we
> still hold 1x rather than doing something like using a File interface,
> or Robert's ideas of fragmenting.
> Anyway, I don't have great ideas. It just seems a shame that committing
> something which *improves* the state of a bug can't actually mark it as
> Fix Released, because it hasn't actually achieved the ultimate goals of
> that bug. (1) is possible, but it seems a bit "hey look at me" to open a
> bug just so that you can mark it fixed.
I deal with this exact situation every day. Literally. Every. Day.
If traceability is really important (and for my employer it is) then we open
a new bug. It's ok (even good) for the bugs to cross-reference each other.
The one thing which must be true is that the scope of "fixed" includes the
whole scope of what was reported. For this reason, we also tend to break up
bugs into multiple reports when realize that we actually have acompound bug
that can't be fixed all at once. It sounds like extra work. It is. But it
is a lot less work than trying to figure out what the truth is six months
later. Especially when a customer is panicing in your ear. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bazaar