[lsb-discuss] LSB bug processing (policy) question

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Apr 4 13:20:27 UTC 2012

> 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).

I avoided commenting at first, but now that two people have weighed in, it
turns out I agree with both:

(1) as the submitter, it can become much harder to keep track of your bug
if it doesn't keep the same ID
(2) bugzilla's clone function automatically attaches the old bug to the new
one (as does the dup resolutuion, fwiw), but does not clone the comments
that may have accumulated in the original bug and may be vital to
understanding and resolving - and it makes more work if you have to trace
back to a different bug.
(3) for me, the reporting statistics of "bugs that were supposed to be
fixed but didn't get fixed in time" wouldn't hold a lot of value

To John: we also close bugs we consider dups (sometimes in reverse order:
if the new bug has a better description than the old one, the old one might
get closed, in which case the old bug's subscribers are pasted into the new
one), which will auto-send email with the other bug's id - but our tracker
is 100% open so hopefully this is more helpful than your example!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120404/5f3ab4e9/attachment-0001.html>

More information about the lsb-discuss mailing list