[Kde-pim] [Bugsquad] KMail 2 and bug reporting

[Darío Andrés]

On Mon, Jan 18, 2010 at 1:47 PM, Thomas McGuire <mcguire at kde.org> wrote:
> Hi,
>

Hi Thomas

> (please hit reply all so that everyone is included in the reply)
>
> as you might know, KMail 2 was just merged back from the akonadi-ports branch
> to trunk in KDE SVN.
>

Yes, I heard about that but I was going to wait a bit to try it ;)

> KMail 2 is almost a completely new product: A big share of the old KMail 1
> bugs are either not valid anymore or are now bugs for a different product,
> like Akonadi or kdepimlibs/kmime. Because of this, I think it is best to have
> a clean start for the bug tracking in KMail 2.
>
> To support this, I have renamed all existing KMail components in the
> bugtracker to kmail1-<componentname>. All KMail 1 bugs should be in one of
> those components.
> I also have created some new components for KMail, which shall be used for
> KMail 2 bugs only:
> commands and actions, composer, config dialog, folders, general, sieve, UI.
> I don't know if those are enough components, if not, please suggest adding
> one.
> If a bug in the old kmail1 components gets confirmed for KMail 2 as well, it
> should be moved to the appropriate KMail 2 component, otherwise old bugs stay
> in the kmail1 components.
>

I think there is a problem with this.... I'm going to detail it later..

> Many parts of the former KMail 1 are now split out into different libraries.
> There is the "Akonadi" product, which has all bugs related to the storage
> layer. Additionally, I have created the product "kdepim", which contains all
> libraries that live in kdepim, which are: libkdepim, libkleo, libkpgp,
> messageviewer, messagelist, messagecore, messagecomposer and messagetemplates.
>
> Additionally, we still have the "kdepimlibs" product for bugs in kdepimlibs.
>

Yes, I was aware of such "subproducts" and I always included them on
my bugzilla queries.
I see that the "libkdepim" bugzilla product was removed, that's ok to
avoid duplication. Thanks!

> Now, as a user, one generally does not know in which of those products and
> components a KMail bug really is. If the product or component is not known,
> the bug should first be filed under kmail/general. Therefore it is the
> responsibility of the developers to move to bug to the correct product and
> component. For some bugs that should be pretty clear, it would be great if the
> bug squad can help there.
>
> KMail 2 bugs should be reported with the appropriate version number, which is
>>= 1.99.
>
> Now, one problem is that incoming bug reports could be filed under the wrong
> version, for example KMail 2 bugs are reported under kmail1 components, or
> KMail 1 bugs are reported under KMail 2 components.
> It would be nice if the bug squad could help here and correct those wrongly
> filed bug reports. Mostly I expect this to happen for bugs that are reported
> against the default component. Maybe it makes sense to redirect the default
> component to kmail1-general, if that isn't the default component right now, at
> least until most bugs are reported against KMail 2.
>

The problems I see with the "current approach" are:
* Both KDE SC4.3 and SC4.4 use KMail1, so we still have ~1 more year
of incoming bug reports for the "old KMail" version. (until SC 4.5
goes mainstream)
* The default bugzilla component for each product is "general" (and
this, combined with the previous item, is going to generate some
additional work as users mostly never choose the right component. We
are going to need to reassign every kmail report to the "kmail1-*"
components)
* DrKonqi reports crashes to "kmail/general" (I can still change it
for KDE SC4.4...; but I can't for 4.3 (may be for 4.3.5...?))

I don't know if there is a way to set the "default component" to
"Kmail1-general" (mattr?). If this can be done, then it will be
perfect.
If this couldn't be done, I would suggest to open a new bugzilla
product named "kmail2" (considering the big amount of changes in the
kmail codebase; and the current amount of bugreports) and leave the
old "kmail" product opened for the incoming 4.3 and 4.4 reports.

As I didn't get any mail from the component reassignment you did to
"Kmail1-*", I guess you modified the bugzilla database directly. If
that is right, then we could also eventually move them back without
generating too much noise for the reporters/devs

(I hope I didn't forget anything related...)

I hope this input can be useful :) I'm open to discussion too.

BTW, is there a reason for the "Kmail1-general" component to have a
capital "K" while the other ones have "k" ? (to show it is special/the
default one?)

> Feedback or questions appreciated.
>
> Regards,
> Thomas



Greetings
Darío A. (bugs.kde.org)

>
> _______________________________________________
> Bugsquad mailing list
> Bugsquad at kde.org
> https://mail.kde.org/mailman/listinfo/bugsquad
>
>
_______________________________________________
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/