Here's a list for coreboot.
https://review.coreboot.org/c/coreboot/+/63797
Martin
Apr 22, 2022, 18:46 by rminnich@gmail.com:
oh oops the person doing that misunderstood me, we'll have to fix it
On Fri, Apr 22, 2022 at 5:41 PM Martin Roth gaumless@tutanota.com wrote:
Hey Ron, I think this is a good plan. We can make a markdown file doing the same. I'm not sure that coreboot wants to record where it's deleted, but instead the branch where it would be maintained. This is the solution I was talking about in the coreboot leadership meeting: https://review.coreboot.org/c/coreboot/+/63754
Take care. Martin Apr 22, 2022, 17:24 by rminnich@gmail.com:
The discussion here has been pretty helpful to my thinking. I think the concerns people are raising are important.
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
This leaves two x86 boards behind, not counting qemu.
But, based on what has come up here, we decided we did not want to leave all memory of old efforts behind.
This is the result: https://github.com/oreboot/oreboot/pull/570/files
Not sure if this would be desired for coreboot, but I am mentioning it here for reference.
Thanks
ron
On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper sam.kuper@uclmail.net wrote:
(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:
- is in widespread use with coreboot, even if long out of production
(e.g. certain server boards or Thinkpad models); or
- is targeted by related projects (e.g. Heads) that coreboot
developers would prefer to avoid unnecessarily inconveniencing; or
- 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 -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org