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
Critical | Core | Contrib | Experimental |
---|---|---|---|
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:
Critical | Core | Contrib | Experimental |
---|---|---|---|
|
|
| <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
- If we decide to protect the master branch, does pushing the maven-release-plugin commits still work?
- If we decide to protect the master branch, how will we perform mass changes, e.g. regenerating README.md or
.asf.yaml
? - Can the checks be overridden in special cases?