<br><br><div class="gmail_quote">On Wed, Apr 4, 2012 at 10:49 PM, Wichmann, Mats D <span dir="ltr">&lt;<a href="mailto:mats.d.wichmann@intel.com">mats.d.wichmann@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div>On another project there&#39;s just been a bit of a debate on how</div><div>to handle bugs that are initially targeted for a certain release,</div><div>then don&#39;t make it and are moved out.</div><div><br></div>


<div>It was proposed that such bugs be cloned with the new bug</div><div>marked as targeted to the next release and the old bug</div><div>closed as WONTFIX.</div><div><br></div><div>This drew howls of protest from some; the argument in favor</div>


<div>was that this way, better statistics could be generated for</div><div>a particular release: you could then track how many bugs</div><div>had been originally tagged, then not fixed due to lack of</div><div>resources or whatever, if you just move them out you can&#39;t</div>


<div>get visibility into that aspect.</div><div><br></div><div>Without tossing in my own opinion, what do people think</div><div>of this as an approach for LSB?</div><div><br></div></blockquote><div><br></div><div>It&#39;s not how bug reports are typically handled in my experience with versioned releases. A bug usually stays with the same issue ID throughout its life, regardless of whether it gets pushed to a later version or not. Creating new bugs to effectively duplicate an existing one seems to just be generating noise. I can appreciate that creating a new bug for a later version may allow better statistics, but I&#39;d question how useful such statistics would actually be (but my interests are likely much narrower than those of others on this list).</div>
<div><br></div><div> </div></div>-- <br>Craig Scott<br>Melbourne, Australia<br>