Hi Nico.
I fully can understand your point of view in this discussion. Unfortunately, we do live in a real world with real companies that are business-driven. With this sidenote in context the world changes dramatically in this regard.
Your request for an early discussion whether this or that decision is acceptable pretends that a silicon vendor is willing to start this discussion fully open at a time where he by himself is not yet clear how the feature in question will finally look like (because once the vendor exactly know how it will look like it is set in stone [or silicon] already). Given this, communication on topics like this is very restricted, even inside a company. Everybody of us has experienced already that teams inside of a big company working on the same project but just on a different facet of it are often not aware of what is going on at the neighbors. Why is that? Well, this is IMHO because in our world more and more work is spread among viewer people. I do not see that this is evil-driven, it is just the lack of time the individuals have to get their job done in a fixed "24-hour-per-day-world". So I guess even if the companies would be willing to follow your approach to discuss things early we still will not get a perfect world. And discussing things implies that it will take some time to get to a consensus. Time, that (I must say unfortunately) is not there anymore since every one wants to have the latest and greatest toy to play with at best already yesterday.
You see how fast this discussion takes us away from technical stuff we all love to do and leads us into spheres where other factors rule the world. Again, I do see your point and deep inside me I full agree with you. I just do not see it happening in the current scenario we have around.
Let's get back to your approach:
set of predefined, blob related questions (to be discussed) should be answered.
Let's take it literally as you want. What if the answer to the question "Would the blob ever be open sourced?" is "No!"? What would be the next action in your scenario triggered by this answer?
As Martin pointed out already, to me it sounds like "To many blobs with no open source in sight and we will reject this platform", too. But I might be wrong here simply because I internally answered the question above for me without it being answered by your approach directly. So, to be able to judge properly on the approach I miss the targeted outcome of your approach (I know that it is just a proposal to start the discussion, I just want to make my thoughts clear here). Because I don't believe that having a set of questions answered honestly by the poor guy, who currently is in charge of bringing in this particular new interface for the blob or the blob itself, will lead to a more open policy at a given vendor. And yet again, answering this kind of questions is real work! Because the poor guy mentioned above now have to have meetings with various internal actors, describe the situation to them and hope that they will be able to provide the answers. In most cases, I guess, he can repeat the asking and explaining on the next linked person a few times. I am not sure if that guy will ever get the time for this relay run, especially if the outcome is not clear or guaranteed.
So yes, we need to stay in a close conversation with the vendors and keep them in a short loop. I am just not sure if we as coreboot alone can get that managed due to the lack of a business-model the vendor would be interested in. On the other hand I feel sorry for the poor guy mentioned here. Just because we are so upset with a particular vendor (due to the past issues we all may have experienced) we should behave correct when it comes to treatment of individual contributors, especially when those are quite new to the community. So instead of barking around on Gerrit and blocking stuff from being developed let us be constructive and provide helping hands and guides on Gerrit and on IRC. If I were the guy in question and I would be welcomed in the community the like, for sure I would feel sad.
Werner
-----Original Message----- From: Nico Huber nico.h@gmx.de Sent: Sunday, November 7, 2021 1:56 PM To: coreboot@coreboot.org Subject: [coreboot] Re: Another year, another blob?
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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org