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

Ingo Klöcker kloecker at kde.org
Mon Jan 18 22:30:50 GMT 2010


On Monday 18 January 2010, Darío Andrés wrote:
> 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.

I second the creation of a new Bugzilla product for KMail 2. Mixing two 
completely different versions of KMail is just too confusing.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100118/261e1e9b/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/


More information about the kde-pim mailing list