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

[Ingo Klöcker]

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.

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.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091219/951cc049/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/