STATUS: working proposal

Context

We currently have PR checks across all Sling modules, but they are not enforced. This has two direct implications:

  • we don't have the convenience for creating simple PRs and enabling auto-merge so the are merged once the checks pass
  • we can ignore the status of the CI checks for "well-known" or "unrelated" issues

In the long run, we are missing on the benefits of solid CI.

Proposal

Module classification

Not all Sling modules are equal in terms of importance, rate of change, and sensitivity of changes. We do not have a set of CI checks that apply to all modules equally. Some modules are sensitive enough to require an additional reviewer (or two), while others should only pass CI checks. There is a special case of the Sling Whiteboard which is a staging ground for experiments where requiring checks does not make that much sense.

The first part is creating a Sling module classification, with four categories

  • critical: modules that, if bugs are introduced, can lead to broken or compromised Sling deployments
  • core: modules that we generally expect to function well and have good test coverage
  • contrib: modules that work well but don't see heavy usage and are maintained on a best-effort basis
  • experimental: use at your own risk

  

CriticalCoreContribExperimental

Sling Engine

Sling ResourceResolver

<others, TBD>

All bundles included in the Sling Starter

Sling Starter

<TBD: subset/all of Maven plugins>

<TBD: subset/all of Feature model tooling >

<TBD: subset/all Maven archetypes>

<all other modules>Sling Whiteboard

The mechanism for classification would applying a label to the GitHub project using Git - .asf.yaml features :

  • sling-module-critical
  • sling-module-core
  • sling-module-contrib
  • sling-module-experimental

Following a classification of critical, core, and experimental module, we could batch-assing the contrib label to all remaing modules.

CI checks enforcement

Following the manual classification of the modules, the following CI checks will be applied:

CriticalCoreContribExperimental
  • Passing CI checks
  • Passing SonarCloud quality gate
  • 2 positive reviews
  • Passing CI checks
  • Passing SonarCloud quality gate
  • Passing CI checks
<none>

Notes:

  • passing CI checks currently require a successful mvn clean install  on Java 11 and 17 on both Windows and Linux. This can be overridden at a per-module level
  • the SonarCloud default quality gate is available at https://sonarcloud.io/organizations/apache/quality_gates/show/9 . It is unclear if we can easily override these checks for all Sling modules, but I think the general approach makes sense.
  • the positive reviews can come from any Sling committer, there are no plans to use a MAINTAINERS  file to require commits from specific reviewers for to automate reviewer assignment

Open topics

  1. If we decide to protect the master branch, does pushing the maven-release-plugin commits still work?
  2. If we decide to protect the master branch, how will we perform mass changes, e.g. regenerating README.md or .asf.yaml  ?
  3. Can the checks be overridden in special cases?
  • No labels