Here's a list for coreboot. https://review.coreboot.org/c/coreboot/+/63797
Martin Apr 22, 2022, 18:46 by [email protected]: > 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 <[email protected]> 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 [email protected]: >> >> > 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] >> > >> > _______________________________________________ > 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]
