<div class="gmail_quote">On Mon, Jun 22, 2009 at 8:59 AM, John Arbash Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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. </blockquote><div> 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. :) -M </div></div>