Technical Steering Committee

Core developers and maintainers

The Technical Steering Committee (TSC) is a team of people who are responsible for keeping the KernelCI project in a good shape and driving its development.

The rules for adding or removing members from the TSC are defined in the LF project charter. Typically, major contributors eventually become members and those who have stopped contributing for an extended period of time may be removed. This is done in agreement with the TSC and the AB.

As of today, the committee is composed of the members listed below with their respective email address and IRC nicknames:

For general discussions, the regular mailing list can be used. To contact only the TSC members directly, the private list may be used instead.

There are essentially three kinds of maintainer roles:

software maintainers
in charge of the KernelCI software components
service maintainers
in charge of the KernelCI hosted services
feature maintainers
in charge of features that span across the whole KernelCI stack
channel maintainers
in charge of the communication channels used by KernelCI

Software Maintainers

At least one maintainer is assigned to each software component. The work involves reviewing pull requests, triaging and reviving old ones, updating GitHub settings and facilitating the development workflow. Having “deputy” maintainers whenever possible also helps with the continuity of the project.

Core tools

The core tools provide the command line utilities and the kernelci Python package used to implement a KerneLCI pipeline.

  • Repository: kernelci-core
  • Maintainers: gtucker, alicef
  • Deputy: mgalka


The KernelCI backend provides a web API to send build and test results and let the frontend dashboard retrieve. It also generates email reports, tracks regressions and triggers automated bisections.


The KernelCI frontend provides a dynamic web dashboard showing the data available from the backend.


KCIDB provices a set of tools to submit kernel test data to a common database.


Simplify the install and maintenance of a LAVA lab using docker container.

  • Repository: lava-docker
  • Maintainers: alicef, montjoie

Service maintainers

Services hosted by KernelCI all need someone to look after them and ensure they stay online and available.

Pipeline / Jenkins

The current KernelCI pipeline is using Jenkins. While this may change with Jenkins X, Tekton or some other framework, the service is essentially the same: orchestrating the builds and tests on

  • Maintainers: broonie, gtucker
  • Components: kernelci-jenkins
  • Resources: Azure, GCE


Several Kubernetes clusters are used by KernelCI, to build kernels and run platform-independent tasks or kernel tests in VMs (static analysis, QEMU…).

  • Maintainers: khilman, montjoie
  • Resources: Azure, GCE

VM Servers

A number of virtual machine servers are being used, to host the and services. They are currently all managed in MS Azure, but this can change over time. The services remain the same. They require SSL certificates, monitoring tools, backups…

  • Maintainers: montjoie, gtucker, mgalka
  • Resources: Azure (VMs, Mongo DB)


KCIDB uses BigQuery as a database engine. This requires setting up tokens and managing the associated Cloud resources.

  • Maintainers: spbnick, khilman
  • Resources: BigQuery, GCE


KCIDB uses a Grafana instance as a prototype dashboard. Additional instances may be set up for other use-cases, such as showing statistics about the KernelCI project in general.

  • Maintainers: spbnick
  • Resources: VM Servers

Docker Hub

All the Docker images used by KernelCI are pushed to the Docker Hub. This requires some maintenance in particular to keep an eye on resource usage and adjust permissions.

  • Maintainers: gtucker, mgalka, apereira

Feature maintainers

Some advanced KernelCI features involve coordination between multiple software components and services, but still require dedicated maintainders to ensure they behave as intended.

Native tests

Tests orchestrated on are called the native KernelCI tests, unlike tests running in external CI systems. This covers integration with test labs, rootfs images, pipeline configuration… anything related to running those tests and getting their results into the database.

Native builds

Just like tests, kernel builds orchestrated on are called the native KernelCI builds.


For every test regression detected, an automated bisection is typically run (with supported test lab types). This involves building kernels, running tests and checking their results in a coordinated way.

Staging instance


All the incoming pull requests are merged into temporary integration branches and deployed on [](] for testing. This is explained in greater detail in the Staging section.

Production instance


The KernelCI components and services need to be regularly updated on the production instance with the latest code and configuration changes. This includes typically enabling coverage for new kernel branches or running new tests, as well as updating rootfs and Docker images with the latest versions of all the packages being used.

It is currently done once a week on average, although deployment may become gradually more continuous as services start to get hosted in the Cloud and run in Docker containers.

Chrome OS instance


The Chrome OS KernelCI instance is dedicated to building specific kernels and running Chrome OS tests on Chromebooks. This is very close to the code used in production but has continuous deployment like the staging one, including open pull requests for the chromeos branches. These branches need to be regularly rebased with any extra patches that are not merged upstream, typically after each production update.

CIP instance


The CIP instance is dedicated to building CIP specific kernels with CIP configurations. Currently the CIP KernelCI code is in production.

Channel Maintainers


This is about keeping the #kernelci IRC channel updated and managing automated notifications sent to it (monitoring services, GitHub and Jenkins integration…)

  • Maintainers: montjoie

All the KernelCI mailing lists are managed via This includes moderating incoming messages and new subscriptions, keeping settings up to date and dealing with changes to the schemes for each price plan.

  • Maintainers: broonie, khilman


The KernelCI Slack channel may be used as an alternative to IRC. However, more people are using IRC so Slack is only there to facilitate communication when IRC is not practical.

  • Maintainers: khilman update emails

Emails are sent regularly with a summary of the changes going into production and minutes from the various TSC and board meetings.

  • Maintainers: gtucker


The KernelCI Twitter account is used to engage with public events, kernel developers and other test systems in particular. It is also a way for the project to quickly share updates about new features or events.

  • Maintainers: gtucker


The KernelCI blog is currently hosted on the Linux Foundation project website using Wordpress. Managing it involves communicating with the LF when needed to make certain changes, and either giving access to people who have a blog post to publish or publishing it directly on their behalf.

  • Maintainers: khilman
Last modified September 3, 2021