From kde-core-devel Thu Sep 18 08:17:25 2003 From: Don Sanders Date: Thu, 18 Sep 2003 08:17:25 +0000 To: kde-core-devel Subject: Re: little reminder on the 3.2 release schedule X-MARC-Message: https://marc.info/?l=kde-core-devel&m=106387225918454 On Wednesday 17 September 2003 18:55, Stephan Kulow wrote: > On Wednesday 17 September 2003 04:59, Don Sanders wrote: > > Me three, for client side imap filtering with optional body > > filtering, html editing support and adding whatever > > private/hidden dcop interface is required to KMail for better > > integration with KOrganizer. > > Hmm, you know how to get a release dude by his balls, right? ;( > > All these features need _massive_ testing, > > it's nothing that you > commit two days before master and be done with it. Without these > it doesn't even make sense to release a beta - especially taking > that I discover a new crash every day with the other kmail features > that went into 3.2 (and there are still some pending that are not > on your above list) ;( > > HTML editing support I would sacrifice (especially taking that I > guess it will open a whole can of worms with the composer), but > korganizer integration and client side imap filtering are features > we promised to deliver with 3.2 (and dimap will most likely not > make it into beta1 either - so without client side filtering at all > we're still only half the way to 3.2). > > I'd like to hear dates from you now. 9th november for a first beta > with all features is way too late when we want to have it done > before christmas (which I would prefer - I sleep bad enough > waking up at times thinking IIMMAAPP ;). 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. I'm aware of one unreported bug with spell checking where sometimes words aren't highlighted as being spelt incorrectly. Also there's the spelling language selection issue but Ingo has taken responsibility for implementing that. And now I think of it an unreported crash with Ad hoc fitlers I have a fix for that as part of my ongoing client side imap filtering work. I would have preferred fixing this spell checking problem before moving on to implementing new features. The problem is in kspell in kdelibs and it's proving difficult to fix, I'm currently stuck on that one but I haven't given up on it. Otherwise IIRC it's been over 6 months since I implemented any new features, and I think within that time most bugs, at least serious bugs in my work should have been found and reported. I did just fix a serious problem with searching, but that was due to a regression introduced recently. Due to the open nature of KDE cvs that's not really avoidable. Regarding KMail bugs and crashes in general. If it's in the encryption system or kroupware code then sorry I don't feel responsible for those areas. Also I prefer to work on serious bugs, and if no one else claims them (like the searching regression) new bugs. Now crashes in general, and specifically IMAP related crashes are an example of what I consider to be an example of a serious bug. Currently rather than than trying to fix IMAP crashes I'm relying on others to do that. I'm betting on them being able to fix those bugs. 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. 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. 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 KMail, and I don't have a (palm) pilot to reproduce it with, it's also unconfirmed. I see 4 major bugs #50707 looks really serious, I believe Till worked on a fix for that (IMAP). #56693 and #61589 are encryption bugs I don't feel responsibility for that subsystem anymore. The remaining major bug #53958 is considered closed by the original reporter, I guess it would be nice to have a time out for pop3 mailchecking, not sure if that is a normal bug or wish, I would prefer to look at this kind of thing once the feature freeze is in place proper. 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. 58269: Should be a wont-fix I think. 54886,61173,63862: waiting for response 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. 61213: Could do with more work, but it's now a normal bug rather than a crash. 63206: Can't reproduce. 63635: Pass Looking at the non-reproduceable bugs: 60278, 61226: non-reproduceable pop3 mail checking crashes. Would be nice to spend some time thinking about these but nothing urgent. 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. You also reported a ghost messages in the outbox problem, that seemed serious. 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. But this bug is actually something I'm trying to solve by working on asynchronous filters. Actually that's the code I'm currently working on in order to make client side IMAP filtering possible! I guess what I'm trying to say is that I'm not aware of any outstanding reported bugs in my work, or serious bugs in areas that I care about, except for IMAP that is already cared for by others, the spell checking bug that I am currently stuck on, and except for Bug:41514 that I am actually currently working on. Which is why I'm moving onto new features. Regarding Bug:41514 unfortunately the new asynchronous filtering system I'm working on is only intended for IMAP filtering and manually applying filters. I'm not intending to port pop, and sending mail over to it yet because it would be way too much work for 3.2. But the good thing about that decision is that it should mean the chance of my work introducing difficult to find/fix regressions is fairly low. 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 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) 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. KOrganizer/KMail integration I really don't see as being difficult from the KMail side given hidden dcop methods, one week should be enough. Multipart/Related mails might have to slip to 3.3, which is a shame. 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. Don.