[Kde-pim] KMail 1 Freeze & Merging of Akonadi port

[Volker Krause]

On Saturday 19 December 2009 18:56:28 Ingo Klöcker wrote:
> On Saturday 19 December 2009, Thomas McGuire wrote:
> > Hi,
> >
> > I'd like to formerly announce that I consider KMail 1 (which is the
> > KMail in trunk) to be frozen forever now. No new features or
> > refactorings should be committed to it. Exceptions are still pending
> > review requests, which that lazy KMail maintainer will really review
> > soon. Only bugfixes are allowed from now on (or merges from the
> > enterprise4 branch that don't violate the KDE freeze, the code for
> > them is written anyhow).
> >
> > The focus now should be on porting KMail to Akonadi and KMime, which
> > happens in the akonadi-ports branch. Any help there is greatly
> > appreciated, it is a huge task. Also, it is quite easy to help, there
> > are many low-hanging fruit to fix, see also
> > http://techbase.kde.org/Projects/PIM/KMail_Junior_Jobs#Help_porting_K
> >Mail_to_Akonadi_and_KMime.
> >
> > Also, I'd like to propose to merge back KMail or even the whole
> > akonadi-ports branch as soon as possible after trunk is open again.
> > Two reasons for this:
> > 1. Merging between those two branches is quite a lot of work, which
> > could be spent on coding instead.
> > 2. Some fixes to trunk are in the danger of getting lost, since their
> > equivalent doesn't exist anymore in the akonadi-ports branch. Those
> > for example are popaccount.cpp, messagecomposer.cpp, much of the
> > message viewer stuff, and many more. I'd hate if that work is lost.
> >
> > The downside of course would be to have a KMail in trunk that is not
> > useable, and we do have some people using trunk for their real mail.
> > Those people would need to switch to KDE 4.4 branch for their
> > production KMail. On the other hand, having a broken KMail in trunk
> > will motivate people to fix it :)
> >
> > The timeline for a fully ported KMail 2 is still KDE 4.5. Should we
> > discover that KMail is not ready enough, we can always not release
> > it, or release the KMail from the 4.4 branch instead. I'd expect that
> > we make it, though.
> >
> > What do you think?
>
> I'm torn. This would be the first time in KMail's history (except for
> the periods where a port to a new version of Qt happened) that KMail
> from trunk is not usable. But maybe it's worth paying this price if we
> want KMail 2 to be ready for KDE 4.5.

First, this depends on your definition of usable here. KMail2 already has all 
basic features (that is it can read and send mail), even many of the advanced 
features work (crypto for example). There is no known dataloss bug, and the 
number of known crashs is rather small as well, mostly proxy model related. 
Of course, it is still incomplete and full of regressions (there are about 
200-300 places still commented out), and we lack a complete migration 
solution. Since the Akonadi port is much more complicated than any port to a 
new Qt version before, this IMHO isn't entirely unreasonable though, for 
trunk.

> IMO, it would be great if KMail 1 and KMail 2 could be installed in
> parallel so that the developers who want to help with the development
> of KMail 2 don't have to use ugly tricks (different install prefixes,
> etc.) to separate KMail 1 and KMail 2.

You'd need to separate data and config for this, which means finding all 
places in the code that search for that and replace "kmail" there by 
eg. "kmail2". Introduces a whole lot more fun for migration, and you'd need 
to be absolutely sure that you found all places, otherwise you'd still have 
to use at least a separate KDEHOME to avoid interference.

And to obtain kmail1 in the first place, you need to build it from the 4.4 
branch, where you'll likely find distro packages for, in which case you have 
it in a different prefix anyway. So, not sure how much we would gain by doing 
this in the end.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091219/419c6bad/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/