Release-impacting changes for 16.08 of KDEPIM

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


On Mon, Apr 4, 2016 at 7:41 PM, Ben Cooksley <bcooksley at kde.org> wrote:
> On Mon, Apr 4, 2016 at 9:55 AM, Sandro KnauƟ <sknauss at kde.org> 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

Thanks,
Ben

>
>> _______________________________________________
>> release-team mailing list
>> release-team at kde.org
>> https://mail.kde.org/mailman/listinfo/release-team


More information about the release-team mailing list