Policies/Dependency Changes and CI

Overview of the problem

KDE makes use of a Continuous Integration system to regularly build and test our software as we develop it.

The CI system is maintained by the KDE System Administration team, who are in charge of procuring the build and runtime dependencies our software required from the CI system environment.

If a required dependency is not provided by the CI system environment, the CI system fails to be able to usefully build or test the affected software.

This creates needs for developers to take care in changing software dependency, and for system administrators to try and procure newly-required dependencies in a reasonable timeframe.

Sorting our wants

There's a couple of things we want out of our development process and how the CI system fits into it. Here's a list:

• We want to have a working CI system that gives us useful results.

• We want to have developer flexibility in terms of using and catering to the latest external dependencies of our software.

• We want the master branches to be realistically buildable by other devs, meaning they need to be able to reasonably procure required build dependencies.

• We want to keep the quality of the tips of our master development branches high.

These wants can be in conflict with each other. For example, "keep the quality of HEAD high" can require dragging in very recenty dependencies when our and the external code need to act in concern to address a problem. On the other hand, "have a working CI system" and "realistically buildable" mean avoiding a dependency no one can get their hands on, as the sysadmin team needs time to update the CI system environment and the number of people who can participate in our development process shrinks otherwise.

Returning to "keep the quality of HEAD high" allows us to make some progress in sorting these wants. A cornerstone of our efforts to do so is to consider regression-type defects in our software as more important than newly-identified defects: Things that worked before should keep working. Breaking the build for developers or the CI system is to be considered a regression, and should therefore be avoided.

This means the sysadmin team needs to be informed of and consulted on dependency changes ahead of time.

The process

The protocol for informing the sysadmin team of dependency changes is as follows. In turn, the sysadmin team also commits to following a number of directives.

• Dependency changes for software covered by the CI system need to be mandatorily submitted through code review. Subscribing the sysadmin team to these code reviews is mandatory.

• The sysadmin team is required to provide input in the review within two weeks. If it is for some reason unable to do so (staff shortages, etc.) it needs to keep the community appraised of the situation.

• In addition to the normal review process, submitting the dependency change to the code repository is allowed
  • ... when the sysadmin team gives a green light by accepting the review.
  • ... when the sysadmin team did not provide input within two weeks but the maintainer of the product accepted the review.

• If the sysadmin team did respond within two weeks but did not accept the change, it can be submitted to the code repository anyway one month after filing the review request if the maintainer of the product accepted the change.

• If neither the sysadmin team nor the maintainer of the product respond to the code review within one month, it can be submitted anyway.

• In general, the sysadmin team is required to try and procure new dependencies within one month. If it is for some reason unable to do, the reasons need to be clearly explained in the associated code review.

The overall thrust of this is to (a) make sure the sysadmin team is in the loop of dependency changes, (b) the sysadmin team gets an opportunity to chime in and slow down the process if needed, (c) maintainers maintain control over their product, but are required to do so in awareness of problems.