[lsb-discuss] LSB bug processing (policy) question
audiofanatic at gmail.com
Wed Apr 4 13:04:37 UTC 2012
On Wed, Apr 4, 2012 at 10:49 PM, Wichmann, Mats D <mats.d.wichmann at intel.com
> On another project there's just been a bit of a debate on how
> to handle bugs that are initially targeted for a certain release,
> then don't make it and are moved out.
> It was proposed that such bugs be cloned with the new bug
> marked as targeted to the next release and the old bug
> closed as WONTFIX.
> This drew howls of protest from some; the argument in favor
> was that this way, better statistics could be generated for
> a particular release: you could then track how many bugs
> had been originally tagged, then not fixed due to lack of
> resources or whatever, if you just move them out you can't
> get visibility into that aspect.
> Without tossing in my own opinion, what do people think
> of this as an approach for LSB?
It'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'd question how useful such
statistics would actually be (but my interests are likely much narrower
than those of others on this list).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lsb-discuss