(I'm not a Coreboot dev/maintainer, so apologies for commenting from the peanut gallery...)
On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
[...] 2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch.
Makes sense.
Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated.
If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future.
Surely there will sometimes be platforms/chips that, for good reason, the community wants to keep in master - even if this would mean rewrites for those platforms/chips re the two matters you mentioned above:
a. not using APIs that future versions of coreboot will require;
b. using code that is being deprecated?
Such "good reasons" could include that the plaform/chip:
1. is in widespread use with coreboot, even if long out of production (e.g. certain server boards or Thinkpad models); or
2. is targeted by related projects (e.g. Heads) that coreboot developers would prefer to avoid unnecessarily inconveniencing; or
3. has active coreboot testers/maintainers able to integrate relevant updates, and is passing all significant CI tests.
Other options we could look at:
A platform has not been sold in X years.
A chip has not been produced for X years.
I can see the appeal of these criteria: they are easy to define. However, they are probably not wise criteria, as they may conflict with one or more of the "good reasons" above, especially reason 1.
A platform has not been tested in X years.
A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?)
These seem much better criteria.
To make them easier to apply, should coreboot comprehensively track, for platforms/chips (roughly as Debian does for packages):
- the current maintainer(s) for that platform/chip,
- the current tester(s) for that platform/chip,
- when that platform/chip was last tested, and
- what the test results were?
I think coreboot already tracks some of this data via https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain.
That being so, I propose some draft policy wording (please change/improve...):
"For any given platform or chip that has ever been targeted by the coreboot project:
- For each coreboot "version" (point release, master, or hardware-specific branch):
- if the platform/chip has been tested on that version, but the test was unsuccessful, the platform/chip shall be labelled *broken* re that version; else
- if the test was successful, the platform/chip shall be labelled *working* re that version; else
- the platform/chip shall be labelled *untested* re that version.
- If the platform/chip has known security vulnerabilities on that version, the shall be labelled *vulnerable* re that version.
- If the platform/chip has a person/team assigned to test/maintain it re master, it shall be labelled *maintained*, unless it has been *vulnerable*, *broken*, or *untested* re master for at least 6 months in which case it shall be labelled *unmaintained*,
- If a platform/chip has been labelled *unmaintained* for at least 6 months, a branch shall be created for it, from the last coreboot point-release for which it was tested and found to be working. Such a platform/chip shall be labelled *relegated*.
- A person/team who merges subsequent updates from master into such a branch, such that the branch becomes acceptable to the gatekeepers of master for merging back into master, and who also successfully tests the relegated platform/chip on the resulting codebase, and who volunteers to maintain that platform/chip for the foreseeable future, may become that platform/chip's maintainer, and upon the relevant changes being merged into master, the platform/chip shall no longer be labelled *relegated* but instead shall be labelled *tested* and *maintained*."
Thanks everyone [...] I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread.
Ditto!
Sam