On April 12, 2022 8:55:56 AM UTC, Arthur Heymans <art...@aheymans.xyz> wrote:
>Hi
>
>Would it make sense to backport your fix to old releases and bump
>> those release numbers to a .1 on the end?
>>
>
>Some see releases as mere synchronization tags & nice PR.
>Some releases are also branches in gerrit but there are none affected by
>this (latest is 4.12 and it was introduced in 4.13).

As you may know, coreboot distributions (talking of Heads specifically here), 
take releases tarballs and apply patches where needed on top of it.

In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 
for its supported boards. I quickly attempted to backport the  relevant patches 
to 4.13 tarball release, unsuccessfully. The alternative would be to move all 
4.13+ coreboot versions to switch to a specific commit in the middle of the 
current 4.16 release, which doesn't seem to be interesting from a stability 
perspective for users, moving production board owners to testers of 4.17 
coreboot release.

The relevant patchset is on top of 4.16, where I haven't found a proper merging 
strategy to backport a good patchset onto 4.13. I attempted to find all patches 
touching the 4.13 introduced new smm2 handler, but conflicts arose when trying 
to cherry-pick those commits in reverse order in the attempt of creating a 
patch that would apply successfully on top of 4.13 extracted tarball.

I believe as well that new tarballs for 4.13.1 and newer should have the 
patchset backported and included and newer branches/tarballs (.1) released, so 
that all coreboot based distributions can easily point to those new tarballs 
without each of them having to suddenly point to a specific commit in between 
releases, 4.16 just having been released, also containing the vulnerability.


>There is a precedent where 4.8 was bumped to 4.8.1 because all boards were
>broken.
>
>I don't have a strong opinion on this.
>Do people really use the releases in production or are most using git
>anyway?

In the goal of coreboot release based distributions, and to properly support 
products/solutions, I am not aware of a lot of projects that are based on 
coreboot rolling release (git). 

If reproducibility of coreboot distribution builds (roms) are also being a goal 
for those coreboot distribution projects, pointing to a git commit is only good 
for testing new introduced platforms, not optimal in creating stable releases 
for already supported platforms, which project codebase changes as well in 
between coreboot upstream releases.


>It's a bit weird to have releases that you'd have to advertise as *don't
>use*, but I've seen us do that in the past (because issues are quite often
>just fixed in master).

In an ideal world, each of those projects would have time to test fully rolling 
releases. But the reality is different. Heads/Skulls/Osboot/libreboot relies on 
coreboot releases to build ROMs for their supported platforms and users.


>
>Kind regards
>Arthur
>
>On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge <pe...@stuge.se> wrote:
>
>> Arthur Heymans wrote:
>> > I think this issue might affect a lot more systems than I initially
>> thought.
>>
>> Would it make sense to backport your fix to old releases and bump
>> those release numbers to a .1 on the end?
>>
>>
>> //Peter
>> _______________________________________________
>> 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

Reply via email to