Time to close some KMail bugs…

With kdepim and kdepim-runtime 4.6 release getting close, I think it’s finally time to squash the KMail 1 bug reports.

What will happen ?

In a couple of hours, I’ll close the KMail product, which means reporting new bugs will not be possible anymore. The bugs audit will then begin.

Several phases are planned :

  • Revisit the KMail crash reports and close the ones that are no longer reproducible with KMail2
  • If a given crash is reproducible, open a new KMail2 report with a fresh and useful backtrace and a link to the old report.
  • Test the ‘Normal’ bugs, close the ones that cannot be reproduced, reassign the reproducible ones to the proper product (kmail2, kdepim, kdepimlibs…)

What to do with the wish reports has yet to be defined. I think evaluating the ones which received the most votes and discard the others is probably the best choice.

How can YOU help ?

You have KDEPIM 4.6 beta 5 installed ?  What about starting with triaging your own bugs ?

Once logged on https://bugs.kde.org, click on “My bugs” voilĂ , you’re ready to triage.

Want more ? visit https://bugs.kde.org/component-report.cgi?product=kmail, pick a category and check whether you’re able to reproduce the original report. Drop a comment to the report if you cannot close it.


Written by krop

22 April 2011 at 14:54

Posted in Bugzilla, KDE, kdepim

8 Responses

Subscribe to comments with RSS.

  1. I really want to help you, cause i love the KDEPIM Suite and use it for my daily work.
    But i don’t know how to install KDEPIM 4.6. If you could provide some information for this, i will try to help as much as i can.


    22 April 2011 at 16:32

    • Please, can somebody help Ubuntu users with that task? Inexplicably, the “Kubuntu Experimental” PPA isn’t updated with KDE-PIM 4.6 beta 5. If I have an experimental repo, I shouldn’t expect only some breakage, but frequent updating. Neon isn’t an option, because it pulls kdepimlibs from master, and also kdelibs and kdebase from master. So no stable KDE 4.6 for Neon users.

      About Fedora, it’s as easy as enabling the kde-unstable repository in the KDE Redhat set. Kevin Kofler and Rex Dieter have, as always, done a great job: Fedora has a safe and stable KDE-PIM 4.6 beta 5.

      Alejandro Nova

      25 April 2011 at 05:50

  2. Is Akonadi with the new qsqlite3 backend recommended as a testing platform?


    22 April 2011 at 16:57

    • No, the recommended backend for a desktop usage is qmysql


      22 April 2011 at 17:00

  3. Disabling the possibility to report bugs against KMail 1 even before a stable release of KMail 2 exists doesn’t sound like a great idea to me.

    You should also be aware of the fact that, due to the continued delays in releasing kdepim 4.6, you missed getting included into several current distribution releases, at least Kubuntu Natty and Fedora 15. This means your end users are going to continue reporting KMail 1 bugs for at least half a year!

    A major change like KMail 2 doesn’t get to your users overnight.

    Kevin Kofler

    22 April 2011 at 20:05

    • Letting users report KMail 1 bugs and knowing that noone will ever fix them is a worse idea.

      Not to mention that most KMail1 reports received during the last months are all duplicates of existing bugs.

      About Ubuntu and Fedora, I suppose you will ship the next KDE 4.6 release,right ? So there’s no reason for not packaging kdepim and kdepim-runtime 4.6 at the same time.


      22 April 2011 at 20:31

  4. Closing the KDE-PIM 4.5 bugs is also a great idea. I think a good thresold is KDE-PIM 4.6 beta 4; anything reported against anything lower than that must be retested or removed. Some quick bug triaging sessions taught me that.

    Alejandro Nova

    25 April 2011 at 05:44

  5. I _really_ hope that kmail2 (and the whole kdepim) will be released only if it will have at least the same features and stability of the current stable version.


    26 April 2011 at 15:41

Comments are closed.

%d bloggers like this: