Ok, I'll try to break this loop here. You are repeating the great bene- fits for a user (that I agree to) even if a blob is involved. And I keep asking why it should happen on our master branch (I don't see how we would take something away by not maintaining everything. Also, I never tried to exclude all blobs). It seems somehow we talk past each other.
Nico
On 10.05.2018 23:26, Julius Werner wrote:
Why should it not be on our master branch? What is your exclusion criteria? To my knowledge the only reason why we ever remove boards from the master branch is because they become a maintenance burden when it's hard to make them fit into new/changing APIs and there's no developer volunteering to keep testing for that board. And in those cases, whether that burden is related to a blob or not, I totally agree that we can consider removing them from master. But I don't see how that has anything to do with whether a blob is mainboard-specific or not. If a board with those blobs is still easy to pull along with the changes we want to make on master and there's someone willing to regularly test it and keep it healthy, I see no reason for exclusion.
On the other side, the general benefits of keeping stuff in master are obvious -- users of that board can benefit from the continued development of coreboot core features. For example, if you have a 3 year old Chromebook like Veyron_Jerry today then the firmware Google ships you is still frozen on a three year old branch, but since it's alive and healthy in coreboot master you can build your own image from there and automatically get cool new features like the persistent CBMEM console. Ideally, it would be best if we could keep everything in master forever... we just decide to drop stuff as a trade-off if it actively prevents us from making forward progress on other boards, but that decision is not directly related to the presence or absence of blobs.
On Thu, May 10, 2018 at 5:10 PM, Nico Huber nico.h@gmx.de wrote:
I've been meaning to respond to your original response, but I haven't had a lot of time to articulate things. You've brought this up numerous times; it sounds like you care what is in the master branch. But maybe not any other branches? And what is the threshold for being in master branch? And what audience is the master branch for? I'm trying to envision what the development and eventual result will be.
You have been focusing on FSP talking about maintaining it, etc, but I don't think that maintainership is falling on people disproportionately any more than other parts of the tree. I do find it a bit ironic that you were te one using FSP for some of your work.
As for the github fsp proper, the license in the headers is weird, as Youness pointed out. But in addition to that, it says IOTG Kabylake H as a release. It doesn't say anything beyond that from a support standpoint. Empirically it may work, but so does the FSP generated by Chrome OS. As I'm sure you know assets can be extracted from recovery images for those FSPs. What's the bar for picking one over the other? I don't believe either can be submitted into coreboot.org blobs repo? Or did I miss where that was concluded?
Anyway, just lots of questions -- not many statements. I'm trying to understand the distinction when I don't see many differences of a situation I think most people would agree is unfortunate.