bugzilla situation

[Thomas Lübking]

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  
>> and
>> 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  
center.
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")  
developers.
DISCUSSIONS HAPPEN HERE

3. stage is the bugtracker itself. In a way it's a tasklist for  
development.
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  
retriggered)
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  
suggests.

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.

You got:
----------
- 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  
for.

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.

===> Suggestions
---------------------
a) the component maintainer can block (and unblock) bugs against Dr.Konqi  
resulting in "kfmclient openURL  
'http://bugs.kde.org/show_bug.cgi?id=123456'"
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.


Cheers,
Thomas