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

[Ingo Klöcker]

On Saturday 19 December 2009, Volker Krause wrote:
> On Saturday 19 December 2009 18:56:28 Ingo Klöcker wrote:
> > On Saturday 19 December 2009, Thomas McGuire wrote:
> > > 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.

Thomas wrote that we'd "have a KMail in trunk that is not useable". So 
it depends on his definition of usable. :-)


> 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),

That doesn't sound too bad.


> and we lack a complete migration solution.

I guess that's the real showstopper for many KDE developers using KMail.


> 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.

I fully agree.


> > 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.

Hmm, all places where "kmail" is spelled out should be replaced by a 
suitable function call.


> 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.

Not necessarily. But I agree that it's probably not worth the pain as 
using both versions of KMail in parallel on the same mail storage isn't 
a good idea I guess. So scratch my idea. ;-)


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/924cdce8/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/