DrKonqi improvement idea

[Teemu Rytilahti]

Milian Wolff wrote:

Hi again,

> While nice this is not required for Niko's proposal. Either the backtrace
> is automatically associated with a solution, or a developer later on
> associates it with a solution or a bug report. In the former case, the
> user gets direct feedback on what's going on. In the latter, he will at
> least get a concise email - at least that's what I have in mind (and I
> think Niko as well).
> 
> The big difference to our current solution is just that users get far less
> emails, like "bug XYZ marked as duplicate". Or mails for developer
> discussions in bug reports, something that most users won't understand
> anyways.

Hmm, indeed, looks like I got carried out there, sorry about that. And yeah, 
I agree with that there should be a way to give a clear message to the 
users.


>> Not sure whether this would work, more manual work all around
>> while the
>> triagers are already overloaded afaik. As much as possible
>> should be done
>> automatically. Though I think the duplicate detector in
>> DrKonqi works quite
>> well nowadays and doesn't allow even submit duplicate crashes.
> 
> Hum how is this more work? Actually I cannot see how this can create more
> work, if at all only the same amount. On the contrary I think Niko's
> proposal can reduce the workload! The reason is that users should then -
> in theory - get a concise, short and readable instruction that should
> explain them how to fix their crash. "Update to version XYZ" for example.

Keeping up the information in two separate databases wouldn't do good was my 
ppint. But yeah, perhaps b.k.o should have some kind of separate field for 
that kind of information, which would be then given out as needed.

> Even in KDevelop, an app where our userbase should be somewhat proficient
> with the whole development process, we get tons of emails because people
> add their "+1 crashed for me as well" backtraces to some hideously old bug
> report. And why? Because they don't read the bug reports. Somewhere in the
> comments there might be a "fixed by commit xyz" message, but they simply
> don't care.
> 
> If now they would see a simple "this is fixed by version XYZ - please
> update", then it would help me personally quite much already.

Yeah, agreed. In my opinion the comment section of bug entries could be even 
more cleaned out, to just contain comments for example. Tens of "marked as 
duplicate of" messages do not bring much more info while disturbing the real 
comments. Mozilla uses an extension called inline history which shows 
changes to bug statuses and also combine successive duplicate reports, 
though the process is apparently so heavy the feature is not enabled for 
users not logged in.


>> > Advantages over current solution:
>> > - bugs.kde.org isn't filled with duplicates
>> 
>> Not sure if this is an issue anymore regarding to crashes.
>> Couldn't find the
>> blog entry related to this quickly, but here's a reviewboard
>> entry: [6] .
>> Anyway, the idea is good nevertheless.
> 
> maybe not duplicates, but definitely about "+1 crashes for me as well"
> messages for long since fixed crashes.

Hmm, yup. The traceparser makes inlined backtraces to be not so verbose, but 
doesn't remove the problem completely.

>> This would be a great plus indeed, though would need
>> adaptation on processes
>> depending on how specific solutions should be shown to the
>> user. If fixed-in
>> tags or similar are set to bugs when they're fixed, that
>> information could
>> be easily given to user in a "this bug is fixed in version x"
>> sense.
> 
> or the developer takes the time to tell people he fixed the bug somewhere.
> seriously, that's not too much to ask of them....

True, perhaps a separate field could be provided, and the comment closing 
the bug could be used if none specified?

>> Some things to consider:
>> - If there would be a separate crash-site, could it be worth
>> to allow crash reports without login?
> 
> maybe in the first step, but once they found an actual crash I really
> think they need to provide an email for asking for feedback and such.

Yup, this comment was more about not having a need to create a separate 
login, as I think that'll still be the barrier for getting reports. But 
yeah, there are two sides in this.

>> - Data sanitation? Ubuntu doesn't reveal the crash reports per
>> default as
>> they might contain something which shouldn't be public.
> 
> how is this related to this proposal? our current solution has the same
> problem and maybe/probably some kind of code in place to achieve that.

Well, basically if the reporting crashes will be much easier (esp. if no 
login is needed) and there'll be loads of more reports, then issues might 
surface on this front. This was mostly food for thought though.

>> - When getting duplicate backtraces from users the bug entry
>> could be
>> updated automatically with the version the crash happened,
>> this would in my
>> opinion be a plus in a sense that "can reproduce in version x"
>> entries
>> wouldn't flood the comment section. Anyway, this is something
>> which could be
>> generally available for all bugs...
> 
> I don't get how this is valuable feedback. If I didn't fix a bug of course
> it will be reproducible in later versions?!

Well, from what I've seen in bko people do ask whether the bug is still 
reproducable, no? I see no reason why this information should pollute the 
comments section, which should be in my opinion used for discussing the 
specifics of the bug.

>> - Is there a need to keep duplicate crashes in the database,
>> maybe for false
>> positives?
> 
> hu? I don't get this one. if it's a duplicate then by definition one
> doesn't need its information because it's already known?!

False positives, if that can happen. Also, this kind of information could be 
used as a base to see from what kind of things bugs are triggered mostly? 
But yeah, just thinking...

>> The workflow could be something like this:
>> 1. User encounters a crash and is asked whether to send a
>> report.
>> 2. If yes, a backtrace is being send to the server.
>> 3. If there's a complete match, just inform the user about it
>> and give a
>> link to a bug report / perhaps allow add a new comment to
>> report?
> 
> only if: bug is not fixed or current version is *higher* than the assumed
> fixed-in version.

Yes.
 
> 8. developer fixes bug, associates a "solution" to the crash, user that
> reported the crash gets an email notification.
> 
> this is pretty crucial and the whole point of this proposal...

Indeed. Sounds good to me.

-- 
Best Regards,
Teemu Rytilahti