SEP
12
2008

KMail BugDay on Sunday

The KDE BugSquad is pleased to announce another BugDay! Come and learn the fine art of bug triage. How might one do so? Join us for a KMail BugDay on Sunday, September 14th (7:00 UTC). All you need is KMail version 4.1 or more recent. That is it! We will provide all the training and support. No programming knowledge is needed. Join #kde-bugs on irc.freenode.net anytime to find out more details. Also, we have a spiffy mailing list and lots of new documentation on techbase. See you there!

Comments

I _will_ take part. That nasty IMAP inbox filters bug still raises its head from time to time (even in trunk). I wanna see it squashed, it's damn annoying.


By JJ at Fri, 2008/09/12 - 5:00am

Finally I'll be able to help in a BugDay ( you always set it on exams time!)

Hope I can help


By Marc Deop at Fri, 2008/09/12 - 5:00am

means KDE version 4.1? Because my kmail version is 1.10.1


By Stephan at Sat, 2008/09/13 - 5:00am

Yes, thats correct. It should probably say "KMail from KDE 4.1".


By George Goldberg at Sat, 2008/09/13 - 5:00am

There's an excellent blog post by Michael Leupold explaining about Bug Triage and the KDE Bugsquad, so if you think you might be interested or want to know more about what will happen on Sunday, it is well worth reading.

http://tinyurl.com/3tnrhu


By George Goldberg at Sat, 2008/09/13 - 5:00am

"You also need a current release of KDE (4.1 is OK, 4.1.1 is good, compiled from trunk is best) and some patience."

Why is compiled from TRUNK best?

I, from a quality management viewpoint, would suggest that it is not only not best but it is not a good idea. What is best is to have the latest revision of the current release branch built from source. Actually, you must have built it from source because otherwise you have no way of knowing if the distro fixed the bug.

Bugs that are filed against the release BRANCH should be tested against the release branch because only a release BRANCH is stable enough for bug testing. It is poor quality management to close a bug because "it works in TRUNK". The fact that it works in TRUNK is probably good information, but the bug should not be considered fixed till it is fixed in the (then) current release BRANCH. The reason for this is that bugs that are closed because they "work in TRUNK" seem to reoccur. Even when fixed in the release branch, they sometimes come back before the next release. Sometimes they come back after the next release, in which case they should be clearly identified as regressions since these should have the highest priority to be fixed.

Yes, this complicates things, but it is clear that KDE does have quality issues. Probably the best way to deal with this is issue to add additional status information in BugZilla.

I also have to wonder if reporting bugs against TRUNK is really the best way to deal with them. Specifically, what action needs to be taken after the TRUNK that they were reported against becomes a release?


By JRT at Sat, 2008/09/27 - 5:00am

Damn I readed this too late. I wish I could read this few days ago so I could get the laptop with me to place where I am now.

Oh, I hope someone would implent the Ctrl+M option to Kmail for better usability like on kopete, dolphin, konqueror, ark and many other applications have becaue of it. The menu hiding is bretty important for clean application GUI.


By Fri13 at Sun, 2008/09/14 - 5:00am