thomas.luebking at gmail.com
Wed Feb 22 18:12:54 GMT 2012
Am 22.02.2012, 16:11 Uhr, schrieb David Faure <faure at kde.org>:
>> In case that a user finds a "true" bug, he can go to the project's irc
>> to ask from someone to
>> open the new bug.
> Doesn't sound very open....
[Disclaimer: Describing a custom, proprietary and vastly expensive system
No promotion, just laying out how it works]
3 stage system:
1. stage and ONLY entrance point for every user is some sort of info
Whether approached by mail, irc or web frontend, the user always ends up
in the same system.
On the other side are the "dispatchers" - the only requirement and task is
to direct the issue to the -assumed- correct component.
2. stage is a helpdesk (by component).
Requirement is some more experience in using the component, task is to
-guess what- help the user or direct them to the component ("core")
DISCUSSIONS HAPPEN HERE
3. stage is the bugtracker itself. In a way it's a tasklist for
Only (core) component developers can file a ticket here and unlike all
previous communication, this one is really permanent (the other two stages
have a lifetime of a month. What wasn't staged in this timeframe has to be
To prevent flamewars on this stage, only component developers, the
original reporter and the components helpdesk team can comment (in doubt
on behalf of later reporters)
=== That however doesn't cover crashes at all ===
From my experience, the greatest gift - and pain - is Dr.Konqi.
Users encounter crashes (bad enough), press the report button (very good
user behavior) and Dr. Konqi either files a bug, a dupe or a bug with dupe
The problem here is that this has the potential to vastly reduce entropy:
Have a look at bug #252817
Try to figure the relevant information (yes, it's about the worst example
i know ;-)
As a user, being attached to this bug helps and tells you nothing.
You wanted to know:
a) is this my bug?
b) why does it happen?
c) does it happen to only me?
d) what can i do to prevent it / help fixing it.
- weird lines with weird numbers
- *** Bug 123456 has been marked as a duplicate of this bug. ***
- Created an attachment (id=12345) [details]
New crash information added by DrKonqi
[ more weird lines and numbers ]
There's actually some very relevant information in this bugreport, you'll
just have a hard time to find it - even if you know what you're looking
There's of course good reason to keep duplicate references as well as
additional backtraces (could be helpful) but there's absolutely no point
in visualizing that stuff (at least not by default) - it's not even
possible to shadow that stuff by some userstyle css.
As a result nearly every "*** Bug 123456 has been marked as a duplicate
of this bug. ***" line has a comment and explanation to it on the other
side of the dupe ("Intel driver bug, uncheck "Suspend compositing for
fullscreen windows" in "kcmshell4 kwincompositing", 3rd tab") - good for
the user who reported the dupe and was not duped by Dr.Konqui or just
found this bug otherwise.
a) the component maintainer can block (and unblock) bugs against Dr.Konqi
resulting in "kfmclient openURL
b) duplicates are stored and can be queried but are no way part of the
plain view on the bug
c) leading to "has been marked as" is mailed to the bug assignees but NOT
posted to the bug
d) as long as a bug is marked a dupe, it is not possible to post to it,
neither by mail, web or Dr.Konqi
e) Every bug (esp. those resulting from crashreports) comes with a sticky
which can be edited any time by the maintainer to provide a summary, so
the first thing the user sees is no "weird lines with weird numbers"
I however don't know whether bugzilla can do this.
More information about the kde-core-devel