https://bugs.kde.org/show_bug.cgi?id=430862
Duncan <1i5t5.dun...@cox.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |1i5t5.dun...@cox.net
--- Comment #91 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to vindicator from comment #19)
> I'm curious why the other posts (specifically older) "has been marked as a
> duplicate of this bug"
Bug is resolved/fixed (and my curiosity upon seeing it referenced in the git
logs is why I'm here) but I don't see that this question was ever answered. So
here's my (explicitly unofficial as I'm just another bugfiler, here and
elsewhere) attempt at an answer...
There are (at least) two general bug-duplicate policies that can be employed by
devs choosing which bugs to mark as duplicates. Some products or bug
installations use one, some the other, and others may default to the first but
choose the second given a strong enough reason on an individual bug basis.
1) Chronological order policy. Newer bugs are always duplicates of the oldest,
original bug.
This could be argued to be the most "correct", but often has the practical
issue described/solved by the more pragmatic policy below. Still it's the most
reasonable default in the absence of a solid reason to override and is thus
favored where such priority-overrides are less common. In my experience
distros commonly have this policy, probably because of their function as
accumulators/packagers of software from various upstream sources.
2) Pragmatic "most useful information" policy. The "original" bug is defined
as the one with the most useful information already posted to it at the time of
the duplicate marking, regardless of which one was actually filed first.
In my experience this policy is more common on upstream original software
source providers, I'd suggest due to reasoning below, but extended to the more
general case (that is, not always will the most informative bug-filing be the
one with the commit-ID attached).
Especially where (semi-)automated crash-report filing is used (as it is with
some kde components and apps, with the user's consent of course), the
often-automated chronologically first bugs may have very little additional
information, while a bug filed later, sometimes only because its author took
the time to collect and add additional information, has more practically useful
information in terms of actually fixing the bug.
A recent bug I filed where earlier bugs were marked duplicates of mine is a
good example. For kde I run live-git versions built myself (using the
gentoo/kde project's build scripts so it's pretty automated) and I normally
update once or twice a week. I found a regression that wasn't there before my
last update, so I checked the git logs to see what changed and then bisected
the problem down to an individual commit. When I filed the bug it had the git
commit ID that triggered the problem in the subject line. There was other
information in the bug as well but honestly the commit ID was probably the most
helpful and the reason earlier bugs were marked dupes of mine.
But bisecting to an individual commit is a non-trivial amount of work and takes
time. By the time I did that there were other bugs reporting the problem. But
despite not being first, my bug was (presumably) considered to have more useful
info attached, as I said, likely the commit ID alone was enough, so other bugs,
including some filed earlier, were declared duplicates of mine.
--
You are receiving this mail because:
You are watching all bug changes.
