bugzilla situation

Fri Feb 24 08:22:40 GMT 2012

On Friday 24 February 2012 21:03:42 Ben Cooksley wrote:
> On Fri, Feb 24, 2012 at 8:06 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> > On Friday 24 February 2012 02:15:54 Sven Burmeister wrote:
> >> Am Mittwoch, 22. Februar 2012, 19:00:26 schrieb Martin Gräßlin:
> >> > Personally I'm not sure whether the MeeGo bugzilla can be compared to
> >> > the KDE one (technical oriented vs. user oriented). From my personal
> >> > experience (KWin bugtracker is felt > 90 % a user support forum)
> >> 
> >> My claim is that most of that "user support" only ends-up in bugzilla
> >> because people did not get help somewhere else, e.g. because only
> >> developers are familiar enough with the code to understand the issue.
> > 
> > No, that is clearly not the case and it's not the case that the users are
> > searching for user support. It is they have a problem and consider it a
> > bug. They don't know, that:
> > * they just didn't find that damn config option
> > * they have installed the wrong driver/distro/whatever
> > * how to circumvent that stupid driver crash
> > * many many more things which turn out to be user support (interesting
> > side
> > node: the second most often reported bug against KWin is Compiz crashing.
> > That says all about the usefulnes of reports)
> 
> Is there a page somewhere (such as on Userbase) which documents these
> broken driver/distribution combinations - and the hardware generally
> associated with it?
no, there is to my knowledge no such page. This is knowledge we actually 
learnt. And I think a page would not fit, more something like a process 
diagram/decision tree which results in a fairly clear solution.
> 
> In regards to the Compiz component, is that something KDE ships - or
> is that something Compiz ships? If it is something Compiz ships, it
> should probably be blocked....
it is an application called "kde-window-decorator" which is part of Compiz. 
Luckily nowadays nobody seems to use Compiz any more, so it's not a real issue 
anymore.
> 
> > and that's what first level support is actually for: filtering the noise
> > so
> > that only the real bugs get through.
> > 
> > Just consider the bug named "kwin-intel" - each of the duplicates is about
> > 2 min work. Each of the duplicates is set by a developer. Each of the
> > duplicates is simple user support. Nothing the developers can do about,
> > but users support was possible (use a workaround or switch to a
> > distribution not shipping broken drivers and failing to fix it in the
> > complete cycle given that the patches exist).
> > 
> >> Most users do not like reporting bugs and thus ask somewhere else first –
> >> and only after that, if at all, they report an issue.
> > 
> > this is clearly not the case with DrKonqui. They just report
> 
> Only if it is a crash. Last I heard DrKonqi included functionality to
> only add the backtrace to the existing report - does this not work
> with KWin?
for which version? 4.6? 4.7? It is no real help that this is now working in 
the latest release :-(
> 
> >> The majority of users
> >> only complains about the buggy piece of software without reporting any
> >> issues. So only if they get no answer on IRC, a forum a mailinglist etc.
> >> they leave their issue with the developer at bugzilla to document it and
> >> wait for an answer.
> > 
> > no, I would even deny that they wait for an answer. Please do a search for
> > WAITINGFORANSWER on the KWin product (I need to add that to my
> > statistics).
> 
> Some users do await replies. Unfortunately there is a not so small
> segment which never read replies.
> 
> >> Leaving the user without answer will not increase KDE's reputation. Thus
> >> the discussion should not be about how to restrict user access to
> >> bugzilla but rather how to help them before they feel the need to report
> >> at bugzilla. Filling out those forms is nothing users like to do.
> > 
> > agreed. The proper way has to be to not let users enter support questions
> > into the bugzilla. My perfect scenario is:
> > a) first level support to help users
> > b) if first level support cannot help it goes to second level support
> > c) second level support identifies the important information from first
> > level support, verifies that there is no bug reported yet and reports bug
> > d) developers can concentrate on fixing that bug
> 
> Note that in many cases, "first level support" as it were already
> exists - however we ask the user themselves to report the bug if we
> believe it to be a valid bug.
I would like to see this process change, quite simple as it gives us the 
information that the user support has already been done. If we get the 
information to where the user information has been done we can read it through 
and don't have to ask again for the same things.
> 
> Unfortunately, without a page as mentioned above with known issues /
> broken combinations which we can point the users to we have no other
> choice other than to believe it is an actual bug - which should be
> reported.
if there is interest in it, we should discuss how such a page should look 
like. E.g. that whenever there is a problem the summary of it goes into a wiki 
page and we verify that the information is correct and that we add things when 
we discover new things.

I doubt we should do something which can be useful to the user. As mentioned 
above it's more like a decision tree to follow: if a and b and not c and d 
then e is the case. I think we need a real first level support which actually 
helps the users instead of just pointing them where the information is to do 
it wrong ;-) (I have an ati so I have to look for fglrx - what a pity the user 
used radeon)
> 
> > in case of KWin that would mean that we get all relevant informations
> > without asking for it:
> > * distribution
> > * version (in case not default of distribution, how installed)
> 
> These should be reported anyway by DrKonqi if it is not
has been broken for quite some time and is only fixed in recent versions. 
Unfortunatly users don't use the latest shit we deliver ;-)
> - as many
> other applications need them as well to determine if a report is
> useful / a duplicate / known issue.
> 
> > * which compositing backend is use
> > * which effects are used
> > * which effects are active when the problem occurs
> > * hardware
> > * driver/version for that hardware
> > * glxinfo -l output
> > 
> > Consider that we have to ask again and again for all those things to find
> > out in the end that it is a known issue with $foo driver in combination
> > with $bar feature. All these things could so easily be handled by a first
> > level support.
> I'm not aware of any documented list of these broken combinations, at
> least at the moment.
yes it does only exist in our heads and I think that is the case for more 
products.

If we want to go for a proper first level support approach, we of course have 
to educate our first level supporters. But before we can do that we have to 
know that e.g. forum.kde.org is seen as our first level support where 
everything should go to instead of bugs.kde.org. For bko I don't need wiki 
pages as it is in my head.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120224/a4c5a80c/attachment.sig>