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