| Summary: | drkonqi should search for duplicate before asking users to login | ||
|---|---|---|---|
| Product: | [Applications] drkonqi | Reporter: | Johannes Obermayr <johannesobermayr> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Some notes: - With "real" do you mean "official" ? - When developing applications based on the KDE Platform, the KAboutData object has a bugAddress() field. If the developer knows his/her application is not an official one, or if its bugs are going to be tracked on a different hosting, then the bugAddress() field can be changed to an email or an URL address. If the developer doesn't change this bugAddress() field, then it is going to be reported to bugs.kde.org (because it is the default value, http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKAboutData.html#a95684a6725a286095710923c3fe8cdf8) I think developers should define if their applications are "official" (bugs tracked at bugs.kde.org) or not. Users may not know if an application is indeed a "real"/"official" KDE application or not. (imagine some kind of Kubuntu specific daemon crashing... the user may not even know what that application is...) About the second issue, it seems to make sense to search for duplicates before the login process, but we should check if there is some kind of technical limitation. Just my two cents. Regards Dario (former DrKonqi dev) A report might be create under the "kde" product for at least two different reasons:
1. The application is tracked in bugs.kde.org, but the crashed binary name doen't match the product name and is not mapped to the correct product. Examples would be kwin_gles from kwin, muon-installer from muon, etc.
2. The application is not tracked in bugs.kde.org, but its author haven't read the document of KAboutData carefully and set the bug address accordingly.
So a report created under "kde" product doesn't necessarily mean that application is not tracked here. Even if that is always the case, I also don't think it would be good idea to ask users to check whether the application is tracked here. I wouldn't expect average users to know how to correctly check and answer that question.
And about sending a email to the person specified in aboutData, unfortunately DrKonqi just can't . DrKonqi run in its separate process, so it can't make use of the aboutData in another application/process. It doesn't receive such information from the command line arguments either. It just receives the bug address.
An alternative solution would be drkonqi maintains a list which records common and well known KDE applications not using bugs.kde.org, and their real tracker address. When DrKonqi notices the crash is from one such application, it can inform users to report the crash to the right place and abort the following procedure.
So change the summary to only reflect the second point.
|
Version: unspecified (using Devel) OS: Linux When a KDE4 application with proper aboutData crashes drkonqi appears and lets report the bug (crash) to bugs.kde.org. There are also apps without slots on bugs.kde.org and they will be assigned to "kde/general". For this apps the user should be asked whether (s)he is sure it is a "real" KDE app (for example one in playground). When (s)he is answers "Yes" it should be reported to bugs.kde.org and an email should be sent to the person specified in aboutData (may with possibility choosing an alternative slot). Otherwise ("No") it should be possible sending it per email to the person specified in aboutData. The search for duplicates should happen before asking the account data for bugs.kde.org. This has four advantages: 1. Users do not have to log in when the bug is already reported 2. Users without an account on bugs.kde.org can see whether the bug is reported 3. Users without an account on bugs.kde.org should be able to report the bug directly to the specified person in aboutData without the need to register on bugs.kde.org. 4. Appelleed on (often not present) brain of users (-> it seems so) only bugs for "real" KDE apps are reported ... Reproducible: Always