Friday January 3rd, 2003: Preparing RC 6

3.1 RC6 tarballs are generated and uploaded for testing.

Monday January 13th, 2003: Decision about 3.1 final

A check of the showstopper list will decide about the final release date.
Tarballs are generated and uploaded as final. Announcement roughly a week later.

Let's wait for Ingo's decision first ;-))

But let's make plans in case he's fine with it :-D

Since IMAP is the most "interesting" (read: difficult) case, and kpartification the most intrusive, I'd suggest the following plan:

• merge easy kroupware stuff (MDN, vacation) and easy make_it_cool stuff (remove dups, search pattern speedup)
• kapp->config() -> KMKernel::config()
• IMAP. Either cached IMAP, then your changes there (FolderJobs, what else?) or vice versa. Your decision. What do your changes depend on?

I disagree with the approach Marc has suggested and I will not be spending my time supporting it.

There was a chance to integrate a stable version of all the make_it_cool changes, that chance has been lost due to Marc's objection.

Now I am focusing on releasing version 0.1 of Kontact. After that I will restabalize the make_it_cool branch and there will be another chance to integrate a stable version of the branch.

Once I have restablized the make_it_cool branch (and before it is integrated) I will welcome feedback from others on bugs.

I might not have said so but I am also against simply replacing HEAD with make_it_cool. make_it_cool was/is an experimental branch where new approaches were/are tested. Things which have been proven to work in make_it_cool should be ported to HEAD. Things which are unfinished or which are known to be unstable should not be ported to HEAD.

Now you might ask why HEAD should be mostly stable although the next release of KDE is months away. The reason is that many developers and also many people who are just interested in being on the bleeding-edge are using HEAD (which is a good thing because this makes it more likely that bugs are discovered long before the release). This doesn't mean that HEAD has to be stable all the time. But it means that it shouldn't be unstable for a longer period of time. And this implies that experimental code shouldn't go into HEAD. That's (in my opinion) what make_it_cool should be used for. That does not mean that all new features have to be tested in make_it_cool before they are integrated into HEAD, but heavy architectural changes should.

> Now I am focusing on releasing version 0.1 of Kontact.
> After that I will restabalize the make_it_cool branch
> and there will be another chance to integrate a stable
> version of the branch.

O.k.. But why do you insist on dumping make_it_cool onto HEAD in one go? What's the problem with integrating it piece by piece (apart from the fact that it is more work which you shouldn't worry about since we have other people, e.g. merge-master Zack, who kindly agreed to take care of this)?

I wouldn't have released the make_it_cool branch on kmailcool.org if I didn't think the enabled features were stable and complete.

Now there is some new stuff (full text index, and BBDB clone) that might take some time to polish. alternatively some of it can be disabled.

So we should probably target the released make_it_cool with the merge instead of current CVS. Have you tagged the release in CVS? Probably not (no obvious tag in cvs log) :-(

Do you have a date we could use for tagging?

> but for the large
> architectural changes it doesn't make sense to try to break them into
> smaller pieces.

The idea is to faciliate peer-review. You can't peer-review a 300K patch. You can, however, review six 50K patches. Peer review is important. Peer review found numerous small buglets and large bugs in your cool code and patches from external developers as well as KMail developers. For a recent prototypical example of peer-review, see the CharFreq changes.

Plus, there aren't much large architectural changes in make_it_cool yet. The only ones (off the top of my head) being kpartification and folder jobs. There're far more feature additions (vFolders, search enhancements, remove dups, ad hoc filters, full-text indexing (who the hell needs that? Didn't you yourself say that a DB backend would be unnecessary and now you implement a DB inside KMail), zero-copy parsing) than arch cleanups (kparts, folderjob). The maintainablilty of make_it_cool is not higher than that of HEAD and that's the metric that I'd measure architectural changes with.

The biggest obstacle I can see is the massive code move w.r.t. kpartification, but then, we could just track the commits made to make_it_cool and - assuming they were tagged with proper log messages - generate a patch for kpartification. You could probably create a self-contained patch in an hour or two - if you wanted.

Plus, the concurrent changes to the IMAP code in both branches, on which we should focus first.

I want this thread to end. Now. The compromise has been reached. Here's what we agreed on:

1. Ingo reverts HEAD to 3.1 and updates the about box (I don't want to see anyone but the maintainer touching that thing from now on) - Ingo please do that as soon as possible.
2. kroupware is merged first (I know the code for cached imap, but Marc could you send all the other diffs from kroupware to the list? I'd like to read over them)
3. I start merging make_it_cool. I start from small things. Oh, and I heard the argument about IMAP changes. IIRC I'm the author of all IMAP related changes for make_it_cool, so stay calm, I'll leave those till the end because a few of them depend on the folder jobs rework. I want to merge small things like - remove dups, system tray, show custom headers, inplace folder renaming and my separation of gui logic from kmfolder - first. Then search folders, then folder jobs, then kpartification.

So the order of diffs would look like:

• remove dups
• system tray notification
• custom headers
• inplace folder renaming
• cleaning up kmfolder gui logic (refactoring of most of the custom icons related junk)
• mainwindow extraction (kmmainwidget stuff)
• search folders
• folder jobs
• kpartification

Now I take some people might have a problem with the above order - so for those that do - I picked that order because some of that code depends on other chunks. I'm not going to be rewriting any of that code just to accommodate it to be working without something it depends on in make_it_cool.

Revert HEAD to KDE_3_1_BRANCH. Of course I didn't remove any files that where added to HEAD.

OK, finished. There were 380 commits processed, all except a handful of them have been split at least into whitespace and functional changes, most into independant changes.

That has involved hand-editing a lot of patches which makes it likely that some will be malformed. It shouldn't be too bad.

Integrate a subset of the changes in the make_it_cool branch. This is a set of changes that is well test by myself and others. The following bug fixes amongst others are included:

• Compilation fix: the certificate dialog now compiles
• Mjr bugfix: Prevent mail loss when kmail crashes while editing a drafts message
• Mjr bugfix: Fix erratic folder changing when clicking on the folder tree
• Mjr bugfix: Prevent mail loss when applying filters

The follow features have been implemented:

• KMail is now a KPart and can be embedded in the Kontact/Kaplan container applications along with other KDE PIM applications.
• Remove duplicates function for removing duplicate messages in a folder.
• Messages can be dragged and dropped on a composer window to add those messages as attachments.
• Deletion in threaded mode is improved, child messages will no longer be scattered when a parent is deleted.
• Multiple messages can now be selected in the search dialog.
• New context menu in the search dialog with Move, Copy, Reply etc. actions for operating on selected messages.
• Search criteria in the search dialog now supports more types of rules and a variable number of rules.
• Faster searching of large messsages.
• 'Search Folders' which are a KMail folder that stores a search expression and is dynamically updated (also known as virtual folders).
• The separate window for reading mail has a context menu with Reply, Copy etc. actions for operating on the message displayed.
• The separate window for reading mail has a tool bar.
• Startup of KMail is faster.
• Switching between folders is faster.
• The contents of all composer windows are saved to disk on composer window creation and then periodically saved to prevent mail loss in the result of a system crash.
• The state of KMail folders is saved to disk periodically to prevent status information loss in the result of a system crash.

Note after start KMail switching to folders for the first time will slow as the format of the .sorted file has changed.
Enjoy!

Don? If the TT mail server has problems and you therefore can't follow our discussions on kmail@kde.org (especially the discussion between Marc and Zack who talked about how they want to do the merge) then you should have read kmail@kde.org through news.uslinuxtraining.com (cf. www.kde.org/mailinglists.html). Marc and Zack spent a lot of time creating hundreds of small diffs.

Nobody expected you to do any merging. It's nice that you tried to help but I'm not sure whether your help (i.e. the huge commit) wasn't counterproductive. You basically stabbed Zack and Marc in the back and made all their work more or less obsolete (well, anyone who is interested in all the small changes can have a look at the patches they created. But it would have been much better if this would have been documented inside CVS.)

If Zack and Marc ask me to revert HEAD again then I will do so. Not because I don't appreciate your help. But because I think the merge can be done in a more transparent way.

You could concentrate on integrating some of the kroupware changes into make_it_cool. But please don't step on Marc's and Zack's feet again in the next few days. Simply sit back, relax and watch Zack and Marc do all the hard work which is very much appreciated by me.