Handling of "partial fixes" and bug numbers

[Martin Pool]

2009/6/23 John Arbash Meinel <john at arbash-meinel.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm wondering what the policy should be for bug fixes that don't go the
> whole way to fix a bug, but at least improve things.

> (So I used "Related to" rather than (..., #109114).)
>
> 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 was just dealing with the other side of this on the same bug
yesterday in fact, marking a bunch of "uses too much memory" bugs as
dupes of this.  Strictly speaking, they may not all be precisely
dupes, because the failure might be occurring at a slightly different
point, but having them separate did not seem very useful.

I think marking a new entry as just related to a bug is ok, but on the
whole I'd prefer having bugs either entirely fixed or not fixed.
Otherwise if we're trying to keep track of unfinished work, as I think
we should be, it makes it less clear whether one unit is finished or
not.

So I'd incline towards doing #1, marking it fixed and then adding a
followon bug for future work.

-- 
Martin <http://launchpad.net/~mbp/>