[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: little reminder on the 3.2 release schedule
From:       Stephan Kulow <coolo () kde ! org>
Date:       2003-09-18 11:55:22
[Download RAW message or body]

On Thursday 18 September 2003 10:17, Don Sanders wrote:
> 
> If there are outstanding crashes or even just normal bugs due to KMail 
> features I've implemented then I would like to know exactly what they 
> are. Especially bugs in features I've implemented since the last 
> release. Bug numbers would be nice.
So far most problems I had are with search folders. They randomly disappear
or make kmail crash. Till fixed tons of problems within hours after I reported
it. It was your fault telling me I can have several of them - so now I use them
as pure man's IMAP filters. Which is kind of a power usage I assume, but still
it's very disappointing - mostly the disappearing of them.

> If I'm wrong and IMAP support isn't stable now or soon then I don't 
> see much point working on client side IMAP filtering, and would 
> rather focus on fixing IMAP crashes.
Well, client side IMAP filtering will benefit from the fixes in the search folders
I assume.

> 
> If there are some other crashes you are aware of (new crashes) that 
> are reproduceable and seem serious I'm interested in fixing them 
> before moving onto implementing new features. I'm also interested in 
> non-reproduceable problems but there's less I can do about those.
That's good to hear. I'm moving through the bug lists of the major applications
and correcting severities as I see them.

> 
> Looking at the list of all outstanding KMail bug reports sorted by 
> vote I see one grave bug #60575, I'm not sure why this is assigned to 
Trying to get this reproduced by the SuSE QA :)

> Then onto the crashes. Ruling out encryption, IMAP and non-
> reproduceable bugs leaves 
> 57342: I think that's been fixed, just not closed.
> 57528: Probably a buggy filesystem rather than KMail bug.
That's escaping from the real problem. NFS is _very_ poorly supported
by kmail. Just change between middle sized IMAP folders and strace
what kmail does in between - and then imagine every sys call is an
IP package.
And above that, kmail's handling of temporary errors ("probably out of
disk space, exiting") is sub optimal ;(

> 58269: Should be a wont-fix I think.
As stated in the bug report: a nicer error message would be more than useful.
As USB sticks with VFAT are more and more common, people putting their
Mail directories on such beasts will come up more and more too.

> 54886,61173,63862: waiting for response
I'd close bugs like 54886 as FIXED - people can reopen bugs that are not fixed.
But problems with kregexp are invalid as we don't use it anymore.

> 59069,61959: Yes if you run out of ram you'll crash, I would like to 
> continue to improve KMail's handling of large messages post 3.2.
I think, it was already improved quite a bit. But in general, it's not of too much
importance. Perhaps again a little message "you're attaching a file sized
larger than 2MB, be aware kmail isn't optimized for such messages and you
might experience problems." might be good enough to stop users from feeling
kmail is just shit.

> 61213: Could do with more work, but it's now a normal bug rather than 
> a crash.
Then change the severity.

> 61568, 55914 are non-reproduceable index corruption based bugs. Index 
> corruption can't be eliminated, but would be nice to try to implement 
> a better recovery scheme, and improve the corruption detection code, 
> I think that can wait until deep feature-freeze.
Would think so. In general I would regenerate the index rather too often than
too seldom :)

> You also reported a ghost messages in the outbox problem, that seemed 
> serious.
I haven't seen it in a while (afaik someone of you changed the way the outbox
is held open). 
BTW: valgrind shows uninitialized buffers in writing mbox indices. I can reproduce
the valgrind error, but can't think of a way the code breaks.

> 
> Looking at normal bugs, none of them strike me as being that important 
> except for Bug:41514 "KMail freezes the UI when checking for new 
> mail". With 631 votes it seem to be the most hated bug in KDE. This 
> is a complicated issue but one of the main problems seems to be 
> blocking actions, specifically piping through spamassassin.
And GPG. And NFS :)

> 
> Which is why I'm moving onto new features.
The question isn't if implementing new features makes sense. It's more
how many of them make sense to target before 3.2. Client side filtering
and dIMAP are hopefully close enough to each other to make them possible
for 3.2 beta and then stabilize it through the beta phase.
 
> In fact I think for client side IMAP filtering the most dangerous part 
> is done and ready for committing now. I would kind of like to commit 
> that, and work on the remaining part, the ActionScheduler, while 
> waiting for bug reports in the first part. I really need to show Till
That's what I'm suggesting all the time. I just want the features to be in
CVS before 3.2beta - making them work is part of the whole beta thingy :)

> 
> what I've done so far anyway. I should have an implementation of the 
> ActionScheduler done by next week, and have it ready to commit to CVS 
> by that week or the week after. Then Till and I have to integrate our 
> stuff give this two more weeks. And a GUI change made to make IMAP 
> filtering optional, I would like to keep this very simple for 3.2 
> just a checkbox in the IMAP account, one week should be ample. That's 
> 5 weeks. (I'm calculating a week as 8 hours work, that's all I have 
> to comfortably spare per week)
The GUI change e.g. could happen after beta1. That's still a shift of 2 weeks
into october. So the most logic consequence is a little shift of the distance
between the betas and move a alpha2 into there end of september (without or
with unfished client side filtering :)

> 
> Moving onto HTML editing. There's a working (but buggy) HTML editing 
> patch now implemented. It hasn't required any major rewriting of 
> code, so hopefully it doesn't open a can of worms and hopefully 
> fixing the remaining bugs doesn't require any major rewriting. 
> Someone else is helping with this now, so maybe it'll only require 
> two weeks effort on my part.
I still would prefer doing HTML editing together with the kompose framework
Zack is working on for post 3.2. But I first would have to see this in
action.

> 
> KOrganizer/KMail integration I really don't see as being difficult 
> from the KMail side given hidden dcop methods, one week should be 
> enough.
That opens the question who is working on it. Cornelius, who got the
hands full with kitchensync? Or Daniel, who got the hands full with
kcontrol (hopefuly :)?
If it all works as nicely as in #60575 I'm not seeing much of a problem
really ;)

> 
> Multipart/Related mails might have to slip to 3.3, which is a shame.
I thought that's part of the HTML editing? Anyway, I have no idea :)

> 
> So I have 8 weeks / 64 hours of work todo. I'm not sure but I might be 
> able to get it done by the October 21. That is assuming that I can 
> actually get my code into cvs, that it isn't veto'd and that before 
> that date no serious bugs are found, or introduced in the features 
> I've already committed. Which makes me wonder about your finding a 
> new crash every day comment, because I'm simply not seeing regular 
> reports of crashes in the features I've implemented thus far. 
Because Till and I try to tackle the bugs right away :)

Greetings, Stephan

-- 
There may be no I in TEAM, but a M and an E.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]