@jans23 questioned future approach of maintainership of (Heads) at https://github.com/linuxboot/heads/pull/1662#issuecomment-2110286678. As of now I own a nv41 given by Novacustom, and I test the changes on it, where Dasharo maintains the coreboot port and where Novacustom+Dasharo+Heads has revenue sharing agreement.
This historical situation will be used in my QubesOS mini-summit last talk (discussion): https://cfp.3mdeb.com/qubes-os-summit-2024/talk/HL9MSV/ as the main example of upstream/downstream versioning, cooperation/collaboration to better the process for the future and clarify expectations of all parties.
Points:
Heads is rolling release. The more bug opened upstream, the more fixes are done early.
If Heads upstream results in early beta tests downstream (from users wanting new Heads features, pushing downstream for releases), those would result in more issues opened upstreamed and less bugs when downstream do releases on top of a Heads commit they select in their release automated testing.
Those beta releases should result in more upstream rolling releases (downloadable and flashable through traditional internal flashing from Heads users) in PR, more eyes, more bugs found, more fixes and better UX in downstream forks and releases.
Thoughts welcome here. No issue raised, no fixes. Then users complaining downstream.
Ideal process would be (my proposition).
Actual board offerings (sold downstream):
Issues should be raised upstream for a Heads commit ID (system information clear on this, less clear with downstream builds: mapping of downstream release hides Heads master used commit ID. Fix: point users into BOM, or me having clear mapping of commits from downstream BOM to upstream Heads commit ID. Not a problem but could be optimized process)
Issues raised downstream should result in issues opened upstream and closed downstream. BOM releated Heads commit ID ideally should be referred in opened upstream issue opened from downstream issue closed.
Collaboration should happen upstream, not downstream: a PR should close upstream issue, and downstream issue should show that upstream issue is closed, leading to downstream issue also be closed.
Issues closed upstream will result in testable PR artifacts, tested to fix issue.
Issue closed upstream -> downstream means that PR fixed the issue, and should eventually result in a new beta build downstream, linking to closed upstream/downstream issues in BOM.
New board offering from downstream:
Once coreboot+UEFI is functional, start collaboration for coreboot+heads upstream
Open WiP PR where collaboration can happen to make things testable, leading to rolling release testable builds from CircleCI, leading to issues opened/closed until satisfaction of rolling release
Once rolling release is satisfying, open beta builds to be testable by early adopters ddownstream
See commit log https://github.com/linuxboot/heads/pull/1793/commits/0b8f7e53be2149f99abcb4eb17330c9fecd3cbc4 to make sure the changes are compatible.
This is a follow up on agreed board name change from https://github.com/linuxboot/heads/pull/1662#issuecomment-2108074986 discussions.
NS50 not sold by Novacustom: only applies to nitropad-nv41 renaming. Suggestions welcome.
Notes:
CONFIG_TPM_PIRQ=0x0Last comment on which this PR acts upon: https://github.com/linuxboot/heads/pull/1662#issuecomment-2110546325 on which I clarified this PR being needed at https://github.com/linuxboot/heads/pull/1662#issuecomment-2112635186 without any answer.
--
This historical situation will be used in my QubesOS mini-summit last talk (discussion): https://cfp.3mdeb.com/qubes-os-summit-2024/talk/HL9MSV/ as the main example of upstream/downstream versioning, cooperation/collaboration to better the process for the future and clarify expectations of all parties.
Points:
Thoughts welcome here. No issue raised, no fixes. Then users complaining downstream.
Ideal process would be (my proposition).
Actual board offerings (sold downstream):
New board offering from downstream: