Hi again,
originally, I was hoping for a more comprehensive discussion about possible solutions for the friction created by late, undiscussed additions of blob-support code. Alas, that didn't happen, and my own proposal below was misunderstood. So I'll try now to provide some rationale.
First of all, I have to say that what I write is meant literally. Please don't try to imagine something between the lines. But if you really feel like you have to, please just ask how it was meant.
On 20.10.21 14:24, Nico Huber wrote:
a recent yet-another-blob occurrence reminded me that I wanted to write about the matter for a long time.
Every few months, it seems (if not, more often), a new blob is introduced to coreboot. Alas, this is often hidden to the last minute, creating unnecessary friction and unfortunate, set-in- stone solutions that haunt us for the years to come.
When I wrote "a new blob" I meant a new kind of blob. Not just another instance of a known blob with the same interface as an existing one, but rather something new that needs its own support code in coreboot.
My proposal: How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs?
IMO, such guidelines could help the developers who are tasked to add blob-support code. If we had a documented procedure, they would know what to do and could justify towards their employer, if necessary, that they need to do more than just pushing the code.
My vague idea is as follows: Before the very first commit for such a new platform can be merged, a
In my experience people often see such matters as rather unpleasant, so they tend to defer the discussion. They might even maneuver themselves into a corner because they are too afraid to bring it up. Having a clear rule when it should happen would preempt such a situation. When some- thing is unpleasant but necessary, it's better to be done with it, isn't it?
set of predefined, blob related questions (to be discussed) should be answered.
Beside exceptional bad-blob situations (see below), answering such questions should be enough to move forward, no matter the answer! We want people to be honest with their answers, hence we mustn't judge them for something their employer committed. (I thought that is obvious).
This should also apply if a new platform just brings the same kind of blobs with it as its predecessor (e.g. next gen FSP). Situations may change and blobs do too. Speaking of FSP, it's actually a set of many blobs. I think questions should be answered for each part of it individually.
This was my attempt to be clear about the scope. If we avoid to forget something from the beginning, we lower the risk to run into awkward situations later.
IMO, just answering all questions shouldn't suffice to unlock the merge. If there's some downside that definitely outweighs the benefit of adding the new platform, it should be blocked until the blob situation can change. For instance, we had in the past blobs that needed to be cus- tomized under NDA per board. Something like that doesn't seem to be useful for a free-software project.
Maybe this was a bad example. Anyway, I thought I was just stating the obvious: There are limits. For instance, even if we set up a procedure like the questions proposed, that should not allow to bring blob-support in that we wouldn't allow without such a procedure.
The whole proposal was meant to ease bringing code in that we can bring in. And if something was so bad that we really couldn't, it would allow us to realize that early enough before people wasted a lot of time. I see people suffering that are tasked to bring in new blob support. I want to help them. I think we could help them this way. Having some unpleasant questions answered would just be a nice side effect. ;)
Nico