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

[Volker Krause]

Hi,

thanks for looking into improving the bug management, very much needed.

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

Filtering probably exists twice because we moved it out of KMail at some 
point. This is of course should be consolidated.

I also agree that having internal (Akonadi) components causes users to report 
bugs in the "wrong" place, as they don't know which part is responsible for 
their bug. However, I don't agree with the proposed solution.

Having shared components underneath the KMail2 product will fail as soon as 
you use a different application to read your email. Kontact for example. You 
of course know that this is nothing else but KMail2, but that's just as 
unclear to most users as the relation between Akonadi IMAP resource and KMail2 
I'd guess.

It gets even worse with totally different UIs (e.g. the Plasma panel calendar 
could see the same KCal/Kolab/etc bugs as KOrganizer).

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

There is also the more fundamental question if Bugzilla is a user or developer 
tool. For a developer it's much more useful if the products/components reflect 
the actual technical layout IMHO.

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

Indeed. In the same way we could link "Kontact/mail" to "KMail2" then.

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

Absolutely.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120707/93ffba15/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/