[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Preventing loss of useful information when closing bugs as duplicates.

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:

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]