[Bugsquad] KMail 2 and bug reporting

[Matt Rogers]

On Monday 18 January 2010 15:47:53 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.

This can be done, in the wizard at least. We already have specific hacks in 
the wizard to display messages for Konqueror and KHTML, so I don't see why I 
can't make it do something else for kmail.

Please file a report against the bugs.kde.org product so that the work to be 
done for this can be tracked.


> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/bugsquad/attachments/20100123/1cc6e77e/attachment.sig