(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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
