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 rminn...@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.ku...@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: >> >> 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 -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
