thanks for sharing your positive experience. I agree, getting these kind of KDEPIM fixes through backports would be a great enhancement for Jessie KDE users.
Do you compile to /opt or do you build proper Debian packages of the upstream akonadi and kdepim?
Though having the backports path after the Jessie release open for additional fixes (or security updates?) would mean that no newer packages can go into sid.
If somebody would spend the work to provide patches for Jessie, would there be a way to continuously update the packages in the Debian infrastructure? Or would that only work with an external repo?
On Thursday 26 March 2015 13:06:40 Martin Steigerwald wrote:
> I think it would be good to have a newer KDEPIM + Akonadi into Jessie.
> Why? The current akonadi 1.13 master branch together with kdepim,
> kdepimlibs, kdepim-runtime from 4.14 branches (as of 4.14.6/7) here runs
> better than *ever* before, including my most annoying bug
> [Akonadi] [Bug 343114] gets stuck on one request that times out, kmail and
> akonadiconsole do not display any mail payloads anymore, stuck waiting
> gone for good as well.
> For the first time in years (!) I didn´t have to restart either Akonadi or
> KMail just to keep it running with *both* my private huge POP3 and smaller
> IMAP and my huge work IMAP setup with crappy IMAP server (Exchange) for a
> week or so (okay, with using the work IMAP for as most as long as a work
> day without logout/login). That said, I have no idea whatsoever what
> commit may contain the fix. But as the mentioned branches are for fixes
> anyway, they shouldn´t contain any major breakage. I didn´t see any
> regression at all so far, and I think I use quite a subset of KDEPIM
> Also due to the MySQL performance improvements, the load on the machine is
> way lower. Not perfect yet, but *much* better.
> Compared with current akonadi 1.13 and kdepim 4.14.2 versions currently in
> sid, this is a *huge* improvement.
> I personally will just self-compile things until newer stuff is available
> via unstable and experimental. But for all the users of KDEPIM in stable
> it would be highly beneficial to have the newer versions in the archive.
> And yes, I know, likely the only way at this late stage would be to
> retrofit them via backports.
> I think for the experience of the stable users it would be highly