Release-impacting changes for 16.08 of KDEPIM

Ben Cooksley bcooksley at
Mon Apr 4 08:16:48 UTC 2016

On Mon, Apr 4, 2016 at 7:41 PM, Ben Cooksley <bcooksley at> wrote:
> On Mon, Apr 4, 2016 at 9:55 AM, Sandro KnauƟ <sknauss at> wrote:
>> Hey,
> Hi Sandro,
>> maybe you can help to make it a smoother 16.08 release for KDEPIM than for
>> 16.04. We now had our PIM Sprint in Toulouse and discussed things that will be
>> done till 16.08 release and have impact for release.
>> * kdepimlibs is going to be split and been removed afterwards (split to
>> akonadi-calendar, akonadi-notes, akonadi-mail, kioslaves will move into
>> kdepim-runtime) - montel is doing the work
>> -> release team (application) need to be informed about the new repos
>> -> distributions wants also a notice
> There is also another repository called "libkdepim" which dangerously
> sounds like a dumping ground, and has already begun to end up as a
> dependency hub of several PIM library repositories (ie. a dumping
> ground repo). Please kill it too.

Please also kill kdepim-apps-libs, and pimcommon, which are also
dumping grounds.

>> *   KHolidays is becoming a framework, John is kicking off the review on
>> frameworks-devel
>> -> release team (application/KF5) need the information about the move
>> * kleopatra is splitted out as single application (has already its own repo)
>> kleopatra will have two different release cyles to follow one KDE Applications
>> for Linux and GPG4Win for windows builds
>> -> release team (application) needs to add this to the next release (can be
>> done already)
>> * messagelib will change it dependecy from libkleo to qgpgme
>> -> we need to make sure that qgpgme is released (because this will be provided
>> by  gnupg) before the change
>> -> ci needs to add this (because it will take a while till it is available in
>> stable distros)
> Please ensure it uses a competent (ie. CMake, failing that, autotools)
> build system.
> Projects that use QMake are a complete royal pain to work with, pretty
> much always requiring patching to be compilable or installable.
> If the build system in use is unworkable, you'll need to provide us
> with patches to fix it's build system to co-operate with the CI
> system.
> CMake / autotools generally have no problem, unless the project
> authors have taken explicit steps to break things (like matching Qt's
> prefix instead of the install prefix you've been given - that's wrong
> and invalid)
>>  * gpgme++ will be move to upsteam gnupg
>> -> release team (application) will need to be informed that they shoud not
>> release it anymore
>> Regards,
>> sandro
> Cheers,
> Ben


>> _______________________________________________
>> release-team mailing list
>> release-team at

More information about the release-team mailing list