> 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. 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? 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". 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. 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). 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? 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. _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
