CI Requirements - Lessons Not Learnt?

Ben Cooksley bcooksley at
Thu Jan 19 07:55:20 GMT 2017

On Thu, Jan 19, 2017 at 6:29 AM, Eike Hein <hein at> wrote:
> On 01/17/2017 11:46 PM, Adriaan de Groot wrote:
>> But CI has a really important function: it shows us the health of the sources
>> for everything; and that's something the release team needs, and the whole
>> community can be interested in. So "opting out" of CI deprives us of a good
>> view of the state of our software products.
> Agreed. But under the proposed document, you can essentially only
> opt out by behaving so badly that sysadmin sees no choice but to
> kick you out, and it labels that as "rude". I think it also
> communicates why we care about CI (e.g. as regression catcher).

Indeed, that has basically been the case.

> This thread has slowed down now - there's been no strong objections
> raised to the current version of the doc. If everyone is happy with
> it, I propose we start linking it from the /Policies/ main page by
> start of February and try to live with it.
> As for the current situation with xkbcommon, it happened before
> we sat down to write this, and I'd say we don't try to shoehorn
> it into the framework after the fact. AIUI it sysadmin/packagers
> are working to procure the needed dependency, so we'll let them
> do so ...

It's already been fixed - by having the CI build libxkbcommon. It was
also required to build an updated version of xorg-macros upon which
that depended.
Libraries that depend on KWindowSystem will have the self-built
libxkbcommon made available to them.

Implementing this also required changes to the general CI
infrastructure for all jobs, to handhold Autotools based builds. We
did something similar for CMake already.

> Cheers,
> Eike


More information about the kde-core-devel mailing list