(DrKonqi2) Application -> Bugzilla Product/Component mapping

[Darío Andrés]

Hi, George Kiagiadakis and me recently moved DrKonqi2 to kdebase.

As you may know, this new crash handler implementation allows to
submit crash reports to bugzilla (only if the provided information is
considered useful enough).
Most of the KDE applications that are supported on BKO have a matching
appName<->BKO product. However some of them doesn't match.
Like appName="dragon"<->BKO="dragonplayer",
appName="plasma-desktop"<->BKO="plasma",
appName="kded4"<->BKO="kdelibs/kded" or
appName="kwrite"<->BKO="kate/kwrite".

In this cases (and just in the meantime we resolve this issue),
crashes which its application doesn't match are filed against
"kde/general" (I can already handle the daily bug report submissions,
I can afford to do some more re-assignations too).

We are thinking we need a solution to this and we thought about several things:

- "kdepackages.h" is actually outdated and it doesn't provide a way to
map appName<->BKO

- Another static map files will also suffer of being outdated if we
change something at BKO (online)

- GNOME implemented this in their .desktop files adding some entries like:
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnome-games
X-GNOME-Bugzilla-Component=same-gnome
X-GNOME-Bugzilla-Version=2.20.3
This approach will also have outdated information if we change something at BKO

- An online (simple) map: This page could give the DrKonqi the current
product/component for some specific appName
Example:
Query "http://foobar.kde.org/bkomapping.cgi?product=plasma-desktop"
will return "plasma/desktop" (and so on) (we need to discuss the
hosting, could it be inside the bugzilla domain too...)
This is a good approach as it can be updated after something is changed in BKO
If the internal map file is stored in the SVN server, the applications
developer could modify it to add their applications or change the
current data.
(otherwise we will have to maintain this file, at least for the most
common applications)
A "version" field could also be added to this approach (we are
currently using "unspecified" as BKO doesn't have all the possible
versions in all the applications)

May be we can use a combined gnome+onlinemap approach:
- Extract data from the .desktop file
Try to submit/Verify at BKO
If the product doesn't exists (it has changed after the .desktop file
was generated/distrubuted), we use the online mapping
Try to submit/Verify at BKO
If the product obtained by the online mapping fails, we can always
fallback to "kde/general".

What do you think about this? Can any other better idea be implemented

Thanks in advance
Regards

Dario
BKO Assistant