On 29.11.23 02:01, Julius Werner wrote:
I don't like superlatives. I don't think it needs to be "completely separate". For instance, when somebody discusses coreboot for a new platform behind closed doors[1]. And they implement something on the same code base. If they did that according to spec, it would be more likely to get accepted upstream, wouldn't it?
I think whether stuff gets accepted upstream or not depends on whether it follows coreboot coding conventions, fits in with our existing APIs and general architecture, etc. I don't think it's really feasible to write everything that goes into the code review and design discussion process down in advance, and even if we could I'm not sure we'd really want to either.
Agreed. And that's why I want to describe things only at a rough, high level. I'd rather see compliance as a basic requirement than a suffi- cient condition. Direct things into the right direction early so there's more likely something worth reviewing.
Do we want to create a situation where someone uploads code they developed in the dark and then tries to force us to take it because "it matches the spec", even though we don't like it for some good reason that we didn't anticipate in advance when writing the spec?
Somebody could try that, sure, but I don't see how that would be worse than the "it's already written" we often hear today. More important, IMO, is if such a conflict would be more likely. If I'd get one "it matches the spec" conflict instead of five "it's already written" conflicts, that would make me quite happy.
I think developing in the open and seeking consensus among all upstream reviewers should continue to remain the officially recommended way to develop in coreboot, and anyone who for whatever reason develops stuff behind closed doors instead needs to understand that they're responsible for dealing with other opinions when they eventually decide to upload, including the risk that the majority of the community says "we don't want this at all" or "we want a complete redesign from the ground up".
I just want to level that risk. And it's not just the development. When somebody starts talking to a silicon vendor behind closed doors, that can set certain expectations about coreboot. If those turn out to be wrong later, that can make future work harder.
If you want to add documentation that explains how coreboot code should fit together and where to integrate certain new features, or just lists general best practices, I'm all for that. We have a bit of that already and we could certainly always use more, or try to make it more organized and discoverable. I would just be wary of calling it anything that makes it sound official and authoritative. The term "specification" usually implies that as long as you follow this thing to the letter, you can _demand_ that your implementation should be considered correct and everyone else who doesn't accept it is wrong. I don't think we want anything like that for the coreboot development process. Helping people do the right thing from the start is great, but it should always remain understood that not everything that goes into the process can be written down in advance and that the final decision is done for each individual patch at review time.
Like I said, I'm not set on calling it specification. And of course whatever we call it, it should have a defined scope, like an intro- duction that says what it applies for and what to expect.
Or is the question more about "up to what point are people allowed to say 'it runs coreboot' when they have out-of-tree code"? I'd say that's an entirely different thing (that I'm less interested in tbh, but maybe others are).
Same here, I guess. I'm mostly concerned about the development process upstream. Not about what people do downstream; if they don't bother me I don't want to bother them.
I don't think we really have that problem in practice yet, and if we ever get to the point where we do I think just drawing the line at "runs 100% upstream code" should be good enough?
That sounds rather infeasible, TBH. You may not know how hard it is to get things upstream when one isn't the first to work on a platform. Working around workarounds of others, maintaining undocumented boards that are already in the tree, having no word in what options a blob offers, etc. I believe coreboot has to go a long way before we can say that 100% upstream is possible for everybody.
coreboot is GPL so if people don't upstream their code there's really only two possible reasons, either they're lazy and unreciprocating, or their code is junk that wouldn't get accepted upstream.
Or maybe the code that is already upstream is junk and it's impossible to fix without breaking some boards? Or maybe we let blobs in that make hackish workarounds necessary that maybe shouldn't even get upstream?
Julius, I think in case of an ideal GPL project, I would agree with you. coreboot is just far from that.
Nico