[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:       Don Sanders <sanders () kde ! org>
Date:       2003-09-19 2:38:21
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]