[Kde-pim] Reminder: BugDays for Kmail on 18/19 and 25/26 August - please join the fun!

Sat Aug 18 12:33:11 BST 2012

KMail2 is not very different from KMail1 (in GUI)
And wishlist is mainly for GUI.
So close them because it's not maintains it's not a good idea.
We can still add them to KMail1

I am agree to close all crash from KMail1 it's normal it changed a lot in 
KMail2 so we close it.

But GUI from KMail2 is the same that KMail1

So this morning +1000 wishes were closed...
I am not sure that it's necessary to implement theses 1000 wishes but a lot of 
wishes  can be implemented.

It's right it takes time to search bug in big list but hide them is not the 
good way.

Regards

Le samedi 18 août 2012 12:19:51 Martin Gräßlin a écrit :
> On Saturday 18 August 2012 11:18:30 laurent Montel wrote:
> > Heu... Myriam
> > I don't understand why you close all kmail1 as unmaintained ?
> > 
> > I thought that you will look at if it's reproductable on kmail2 and
> > migrate
> > to kmail2 or close it.
> > 
> > But close all kmail1 bug is a very  bad idea
> 
> speaking as a heavy bugzilla user with a clean database I have to disagree
> on this point.
> 
> In my humble opinion just closing all KMail1 bugs is the only possible and
> sane option at hand. Let's just face the facts: there are 1190 open KMail1
> bugs and an additional 692 open KMail 2 bugs. This is all without counting
> the wishlists items.
> 
> Now I think I can provide some insights in what that actually means. With
> KWin we have gone through a transition which is in some regards similar to
> what KMail has gone through. The KWin today is a completely different
> application than the KWin in 2007. Our max of open bugs (+wishes) had been
> around 800 open bugs and now we are down to around 200 open bugs and wishes
> I don't count because they are in a state that I can use it to track my own
> work.
> 
> So we see the numbers are a little bit lower than what we face for KMail. My
> experience is that it takes one hour to triage bugs so that we have ten
> bugs less. The more bugs the longer it takes to triage. Another experience
> is that the older the bug the more difficult it is to confirm whether it is
> still valid or not. In that regard KWin and KMail1 are very similar. To my
> knowledge now with KMail2 KWin is the oldest still in development
> application of the KDE application suite.
> 
> A crashreport for an old version is completely worthless. The code fragments
> don't match any more, it is impossible to say whether the crash is still
> reproducable or not. The only possible chance is to ask the user whether it
> is still valid. But this is actually an insult to the user. Uhh we haven't
> cared about this for three years so now could you please tell us whether it
> still applies (oldest crash report for KMail is from 2005, last modified in
> 2007). Again I have gone through that and closed bugs and wishes which
> started with "Imported into bugs.kde.org".
> 
> The state the KWin bugtracker was in, meant that it was not usable for
> fixing bugs. If I had half an hour to work on bugs, I spend half an hour to
> find a bug which could be fixed. Now if I think about the state of KMail
> bugtracker I cannot imagine how that can be of any help. Now after the
> cleanup I have searches giving me bugs I could instantly start to work on.
> No time wasted.
> 
> From my experience users are just fine with closing the old bugs. You cannot
> imagine how often I got a "oh I completely forgot about that issue". Also
> users like it if you are as honest as possible. If you tell them that the
> bugtracker is a mess, they understand it.
> 
> So my personal advice is to close all KMail 1 bugs with a nice and
> explaining message and asking the users to report a new bug if the issue
> still applies for KMail 2 as of 4.9.0. Something in the area of:
> 
> "Thank you for reporting this issue. We are very sorry that this issue could
> not be resolved untill now. In the meantime the development switched from
> KMail 1 to KMail 2. The transition to KMail 2 fixed many long standing
> issues we experienced with KMail 2. The changes are so large that it is not
> easy to verify whether a bug is still valid or not. Unfortunately over the
> time the amount of bugs accumulated to more than 1000 open bug reports.
> Because of that we close all bug reports as unmaintained. We are very sorry
> that we do not have the time to look at each bug individually to verify
> whether it has been fixed or is still valid for KMail 2.
> 
> We kindly ask you to give a try to our latest version 4.9.0 released on
> August 1st and give a try whether the issue you reported is still valid for
> KMail 2. In case it is still valid we kindly ask you to report a new issue
> against KMail 2.
> 
> Thank you for your understanding and thank you for your help in improving
> the quality of KDE Software."
> 
> Please use your available time and that of the volunteers in the best
> possible way. Go through the already huge list of KMail 2 bugs and clean
> that up. I have been shown yesterday an issue reported agains KMail 2 were
> a user experienced data loss monthes ago and nobody replied to the report
> yet. It is very difficult to argument that KDE developers care about the
> users if one is shown something like that. Please work on what matters and
> thanks for taking care of KMail :-)
> 
> Kind Regards
> Martin Gräßlin
-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
_______________________________________________
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/