little reminder on the 3.2 release schedule

[Don Sanders]

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.