Bugreporting barrier is too low with the new Dr. Konqi

[Darío Andrés]

On Tue, Nov 3, 2009 at 9:17 AM, John Tapsell <johnflux at gmail.com> wrote:
> 2009/11/2 Darío Andrés <andresbajotierra at gmail.com>:
>> - Make the duplicate search step a required one (currently it is
>> stated that duplicate search is "optional", as some users can't
>> interpret/read backtraces or identify the situations). And if the
>> reporter can't find any possible duplicate, he/she needs to explicitly
>> state so <- not sure about this.
>
> Go for this, including the "explicitly state so".
>

Mh, ok, this could be implemented...

> If there are any bugs with a duplicate back trace then either:
>
> 1) The user cannot tell if it's a duplicate or not.  In this case, I'd
> rather just assume it _is_ a duplicate, and ignore.
>
> 2) If the user _can_ tell it's not a duplicate, despite the similiar
> backtrace (which in itself is unlikely imho), then make so that they
> really have to state that it's not a duplicate.
>

The problem I see here is that the backtrace matching logic is not
always reliable. You could be comparing an incomplete backtrace with a
complete backtrace. (some functions missing), and even in that case
the incomplete backtrace could be useful (the missing functions are
not needed to determine the crash cause)

>
> In the case of a duplicate bug report, it would be nice to immediately
> tell the user
>
> 1) Whether it is already fixed.

Yes, I could try to achieve this (if it is duplicate, load the parent
report information and check for its status)
It would be easier if bugzilla had an option to only list "main"
reports (list reports which are not duplicate of another one); so only
the real reports will be listed and possible duplicate and the
reporter has to check less bug reports in order to determine if it
his/her bug is a duplicate or not.

> 2) Which release of KDE will have the fix

This is not really easy or reliable, the target milestone flag of
bugzilla is not really used everywhere, and even if it is used it
could not match the real situation. A complicated solution will be
parsing the comment that include the log of the SVN commit that closed
that bug report (considering that it was closed by a SVN commit, which
is not always true), getting the svn revision and comparing the
versions with the one in the SVN server....

> 3) Possible workarounds
>

If there are possible workarounds there should be listed in the
comments of that report already. But I guess there is no reliable way
of detect such workarounds without using some tag in the comment or
something....

> I'm not sure which of these are actually possible with bugzilla.
>
> John
>

Regards
Darío A.