On 5/5/21 10:56 PM, Julius Werner wrote:
Hi Julius,
Sorry for being a bit late here, but I wanted to second what Nico said. It's important to not add undue burden to the development process. I think the master branch is meant for development, not for shipping long-term stable products. If you're installing coreboot in a train or medical device, then why on Earth would you want to rebase that onto the latest master after you have stabilized?
I didn't said anything about "latest master", this can be any particular point in time that address given need in most efficient way.
There are many reasons for rebasing or updating firmware to name few security and maintainability. Second case is interesting since, if you maintain 5 projects which are 4.12 based it is way different then maintain 4.0, 4.6, 4.9 etc.
Cut yourself a private branch and cherry-pick fixes back to that as necessary.
It is way easier to say then to do. Cherry-picking with so dramatical changes across the tree is asking for dependency hell. I will argue this is not economically feasible for most projects.
AFAIK as community we do not endorse UEFI/edk2-like development that happen couple years ago, and probably still going on, although things getting better. That development model created code base for every microarchitecture and let them live their live without any backporting. I was BIOS Engineer that time and don't think this is valid approach since that model lead to debugging and fixing the same bugs multiple times. Even if branched project developed something important or found bug it almost never land in upstream.
As an open source project, coreboot doesn't have anywhere near the resources to do enough QA to guarantee that the tip of the master branch (or any branch or tag, for that matter) was stable enough to be shipped in a product at any point in time... even Linux cannot do that, and they have way more resources than we do. It's always best effort, and if you want to put this on something you want to sell for money, you'll have to pick a point where you take control of it (i.e. cut a branch) and then do your own QA on that.
This is what we doing right now.
I wonder if community and leadership agrees with "setup your own QA" approach.
We will advocate for improved and extended QA for coreboot and any other OSF, since without that working and doing business is nightmare simply blocking growth.
3mdeb doing Linux maintenance for industrial embedded systems, so we can easily compare efforts related to coreboot and Linux maintanance. IMO Linux doing quite well and setting up stable, LTS and SLTS (10 years support) is huge win and clear understanding expansion of project to the realms where stability is key factor. Linux can be maintained way easier and came with more and more QA guarantees.
(...)
For the case mentioned with ACPI compatibility, I think it's a bit different -- since coreboot versions can't be tied directly to OS versions, there's value in trying to maintain some back and forwards compatibility for the interfaces crossing that boundary, and I think we generally try to do that where we can. We can try to codify that if people want to. But I think it should be something that encourages maintaining compatibility while still allowing for flexibility where necessary... i.e. the guidelines should be written mostly with "should" and not "must".
Agree with that point.
I'm okay with maintaining a "running log of major changes" as long as it doesn't create too much of a hassle to maintain. coccinelle spatches can be encouraged where it's useful but I think they should always be optional... some migrations can be easily represented like that but others not so much. And if I'm flipping the arguments in a function that's only used 2 or 3 times in the whole tree, it's kind of overkill to write an spatch.
+1
Best Regards,