[Kde-pim] RFC: Removing and merging bugzilla components

Andras Mantia amantia at kde.org
Fri Jul 6 12:56:16 BST 2012


Hi,

 I vaguely mentioned a proposal about removing and merging some bugzilla 
components at Akademy, and although not everybody agreed, not everybody 
interesed was present either, so I state here once more.

The suggestion is basically about hiding Akonadi (and probably nepomuk as 
well) from the user as much as possible.

Let's take the KMail example: the KMail2 product has a lot of components, 
some have its duplicates in Akonadi (filtering), and from the user point of 
view quite some is missing. Like how to report an IMAP bug for KMail? How to 
report a POP3 bug? How and WHY should a user know those are part of 
something called Akonadi?

At first sight from a developer point of view it makes sense to have the 
Akonadi product and the corresponding components per Akonadi resource. But 
then an Akonadi developer must follow all KMail bugs as well to move the 
reports to the right component. Or a KMail developer should do that. In any 
case this is some extra work imo.

If we have everything in KMail (and for the calendar part in KOrganizer, 
etc), we have them where one would expect it. Developers could just as 
follow the right component in KMail as they would follow a component in 
Akonadi. Akonadi itself should be reserved for the server or components that 
have no interaction at all with users.

This will screw up statistics, I know, as Akonadi bugs will show up as KMail 
application bugs. But in the end they are, from the user's point of view.

And alternative solution would be (if it is possible with bugzilla), to make 
the KMail components a "link" to the Akonadi components. So if a user 
reports an IMAP bug for KMail, it actually ends up in the Akonadi IMAP 
resource component. That would be the best.

In any case, even if you don't agree with the above we should do one thing: 
not having duplicate components (again filtering has an entry in kmail and 
akonadi). That really makes hard for both side to report and identify the 
reports.

Andras

PS: I volunteer for the reorganizing itself once we have an agreement.

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list