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