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

[Christophe Giboudeaux]

Hi,

Sorry for the late reply, I'm quite busy actually.

On Friday 06 July 2012 14:56:16 Andras Mantia wrote:
> 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.

I agree on some parts but disagree on other ones:

- Bugzilla is a developer tool. It's the place where a developer sees which 
bugs he has to fix and can communicate with reporters. 
On the other side, forum.kde.org is a user tool, as in: "a place where users 
can communicate with other users"

Having an Akonadi product makes sense to me. It's there for bugs related to 
the Akonadi server and the Akonadi resources.

Also note that removing components will prevent users of older KDE versions 
from reporting bugs (drkonqi has a mapping file in kde-
runtime/drkonqi/data/mappings)



> 
> 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.
> 

Agreed but I would clean the "kdepim", "kdepimlibs", "KDE PIM Mobile", 
"kresources" products instead of the Akonadi one.

Christophe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120715/1fcd34ee/attachment.sig>
-------------- next part --------------
_______________________________________________
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/