we may be saying the same thing, but that commit in our file is the "check this out to get this board" ref.
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]
