From kmail-devel Fri Sep 19 02:38:21 2003 From: Don Sanders Date: Fri, 19 Sep 2003 02:38:21 +0000 To: kmail-devel Subject: Re: little reminder on the 3.2 release schedule X-MARC-Message: https://marc.info/?l=kmail-devel&m=106393822630073 On Thursday 18 September 2003 21:55, Stephan Kulow wrote: > 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. Personally I haven't tried search folders with IMAP. I'll set up some and see what problems I encounter. It is pretty cutting edge. But really I don't know what problems people have if they never tell me or at least write a bug report. (And I'm still missing a bug report for this, I still don't have clear descriptions of any outstanding problems). > > 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. I'm lacking a bug report on this. Personally I don't use IMAP for day to day work yet, which is a reason why I'm currently relying on others to fix bugs with it. I really need client side IMAP filtering before I can really use IMAP for day to day mail reading. Once client side IMAP is implemented I should use IMAP more myself and start to fix problems with the IMAP support, like this, assuming that they are reported to me, or the bug system. > And above that, kmail's handling of temporary errors ("probably out > of disk space, exiting") is sub optimal ;( I believe exiting in the case of a disk error for a mail store operation is appropriate. It's better than continuing and losing mail. > > 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. Yeah, there's a regression here, originally the error message I wrote implied there was a disk error and maybe the problem was not enough free disk space. Now the error message assumes incorrectly that all disk errors are due to out of space. > > 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. Sounds sensible. I do consider crashing on retrieving large messages to be a serious problem. > > 61213: Could do with more work, but it's now a normal bug rather > > than a crash. > > Then change the severity. I'll probably get to it sometime, but if I keep swapping out the client side IMAP task it'll never get finished. > > 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 :) There's a risk of losing mail. Currently when a problem with the index is found compaction is disabled. So best to prompt the user before regenerating the index and re-enabling compaction. > > 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. The Kompose framework won't magically implement HTML support, someone still has to do that work, the tasks are somewhat orthogonal. > > 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 :)? I'm just planning on doing the KMail side. > If it all works as nicely as in #60575 I'm not seeing much of a > problem really ;) The current dcop interfaces were kind of implemented in a somewhat care free way. Maybe a good idea if KOrganizer doesn't tell KMail to delete mails. > > 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 > :) Outlook is fond of sending Multipart/Related messages, or at least it used to be. It's important for communicating with Outlook users. > > 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 :) That's nice, but please remember what I'm not told about I don't know about. It's seems mainly IMAP problems are what is concerning you. I'm not aware of having introduced any problems in IMAP support, but I am aware that it has substantial room for improvement. Before I can debug it I need to enhance it so that's it's usable for me, and that's what I'm doing with client side IMAP filtering. Although now I'm thinking/remembering that IMAP search folders might be a good alternative to client side IMAP filtering. Don. _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail