[Kde-pim] KMail 2 bug tracking for the KDE SC 4.5 release

[Thomas McGuire]

Hi,

On Wednesday 20 January 2010 13:07:22 Thomas McGuire wrote:
> On Wednesday 20 January 2010 11:04:09 Volker Krause wrote:
> > On Tuesday 19 January 2010 23:14:38 Thomas McGuire wrote:
> > > for KMail 2, we need to keep track of the blockers for the KDE SC 4.5
> > > release and also keep track of regression that were introduced with the
> > > Akonadi port.
> > > 
> > > For the blockers, I have created a meta-bug. All blocking bugs should
> > > block that meta-bug.
> > > The meta-bug is
> > > https://bugs.kde.org/show_bug.cgi?id=223438
> > > A list of issues in there can be found under
> > > https://bugs.kde.org/showdependencytree.cgi?id=223438&hide_resolved=1
> > 
> > This list contains minor cosmetic bugs as well, such as 223477. So, you
> > might want to define what you consider a blocker then, so everyone uses
> > the same criterias. Personally, I would not include such minor issues
> > here.
> 
> The reason I added this bug is that the maintenance tab is quite obviously
> broken. Yes, it is a little thing, but we have such broken UI everywhere.
> Shipping a KMail with a UI that broken all over the place is IMHO not
> acceptable.
> If only a few of such UI breakages would remain, that would be ok, but
> right now there are too many, and therefore should be fixed.
> 
> I agree about having better criteria for this, especially when it comes to
> priority and severity. Right now, this bug has normal severity and
> priority, I am not sure if that is right.

I've come up with the following for priorities:

First of all, the severity field is unused, only "wish", "normal" and "crash" 
should be used here, which has sharply defined criteria.
Permanent freezes should be marked as "crash".

Now to the priority field:
VHI - All bugs that make KMail completely unusable for any sensible thing and 
      even hinders testing. Examples of such bugs would be saving or sending    
      messages not working, the message list not loading after clicking a 
      folder and such
HI - Major loss of functionality. A really important part of KMail is simply 
     not working. An example would be automatic filtering not working, or the  
     search function not working.
NOR - This is a bug that would make KMail useless for day-to-day usage. Such 
      things include missing navigation in the message list, not working jump 
      to folder dialog or anything else that makes using KMail a pain
LO - A bug that is plainly obvious to the user, but normally doesn't affect 
     day-to-day usage. An example might be the broken maintenance tab.
VLO - A minor glitch that usually doesn't strike out

Lastly, the criteria whether a bug is a KMail 2 release blocker: This simply 
means that I, the KMail maintainer, wouldn't like to release KMail 2 with this 
bug still being present. Yes, that is subjective, but there has to be some 
benefit in being the maintainer :)
Blocker bugs that are VHI, HI or NOR will _certainly_ block the release. Also, 
should there be too many LO priority bugs, that would also potentially block 
the release.

I hope these guidelines are clear by now. It is certainly not always easy to 
use the right priority for a bug.

The main benefit of having priorities is that developers just need to look at 
the bug list to see which important bugs need to be fixed.

Regards,
Thomas
-------------- 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/20100122/dd52a0df/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/