Preventing loss of useful information when closing bugs as duplicates.

Andrew Farris lordmorgul at gmail.com
Sun Feb 10 10:44:49 UTC 2008


Lex Hider wrote:
> Couldn't removing a duplicate remove comments just like I'm suggesting that 
> marking duplicate add them.

I'm sure it could yes, but it would be a more significant change to bz codebase 
than a script that copies comments into the duplicate.  You're talking about a 
pretty broad feature for upstream bz probably, and since redhat is heavily 
modified...

> Is the use case of bug triager making a mistake a valid enough reason to 
> discount this feature?

Consider that there are other issues.  A bug may have only one arch set; if a 
duplicate of bugA with a diff arch is set as duplicate of bugA then bugA would 
need to have its arch set to indicate both.  The copying of comments does not 
adequately mix the information without doing those kinds of steps... and if you 
mix comments then people won't go look at the dupe bug itself. (which is the 
whole point of your suggestion, so they don't have to)

Could be a 'duplicate bug' but being seen in different versions, etc.  Are you 
sure piling lots of such comments into one big long list is an effective way to 
organize the info?

What you've suggested here could really be a loss of information as much as it 
is a way to prevent that, imo.  A dupe is not that hard to go look at if enough 
info to fix it is not present in the one you're looking at first right?

Although it might be nice to have a cleaner list of bugs that are dupes, and 
maybe an indicator of the number of comments on that dupe bug though.  Something 
like:

Duplicates:
bug#  component arch #comments
bug#  component arch #comments

I think that makes it easier to find dupes with content to look in on.. Just my 
2c on the idea. (a duplicate isn't even necessarily the same component)

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----




More information about the fedora-devel-list mailing list