New subject: Document branch boards [was: Quark deprecation]

23 Apr 2022

      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

Re: Deprecation of the Intel Quark SoC