Determining Simon Glass's future in the U-Boot project

[Casey Connolly]

On 6/4/25 15:15, Casey Connolly wrote:
> Hi Tom,
> 
> On 5/28/25 19:59, Tom Rini wrote:
>> Hey all,
>>
>> First, I am not happy to be writing this email. But at this point, I
>> feel I have no other choice, for the good of the overall project and
>> community.
>>
>> Back in January[0] of this year I made a post with almost this same
>> subject line. At that point there had already been a number of problems
>> working with Simon and the overall community. I did not include a list
>> of links. At that point the easiest answer would be to go to the mailing
>> list archive, pick any thread that Simon and I had and see the long
>> disagreements. This trend has fundamentally not changed. And while I
>> started this out with some threads and my summaries of them, instead I
>> want to point to this email I sent this mornig:
>> https://lore.kernel.org/u-boot/20250528170533.GE100073@bill-the-cat/
>>
>> And to repeat what I said there, Simon needs to decide if it's more
>> important to work with the community or have his way every time. Simon
>> cannot have both. Simon needs to accept that some things he think are
>> good ideas have been rejected or he needs to fork off from U-Boot. Or he
>> can ask the community to take over as the project head. If the community
>> wants Simon to run things, I will step down and just be an individual
>> contributor again. Five months of this experiment shows me that it's not
>> working at all and will only be a bigger problem as time goes on.
>>
>> And, I mean it. I cannot take the additional stress of what new problems
>> await me every morning. I do not take the above lightly, but I do not
>> think the project can become healthy moving forward without some
>> resolution here and quickly. While I won't claim my time as the head of
>> the project has been perfect, I have tried my best to always be honest
>> and fair and to seek compromise.
> 
> You've been nothing but encouraging to me as a new contributor and 
> custodian, and I really can't imagine U-Boot without you leading the 
> charge.
> 
> Simon has been repeatedly engaging with people unproductively, wasting 
> time and delaying valuable contributions. His complains tend to come in 
> the form of vague hand waving about how things should be with seemingly 
> no attention given to the actual intentions of the patch and dealing 
> with the reality of how U-Boot works today. With so much attention given 
> to his ever-diverging fork I can only imagine increasing confusion about 
> how U-Boot actually works when it comes to reviewing upstream patches.

fwiw I am missing a lot of history here which I probably should have 
considered more while writing this. I have had good discussions without 
Simon about some topics, but particularly in the last few months it has 
become much more difficult.


> 
> Referring back to: https://lore.kernel.org/u-boot/1c1bcd1e- 
> bec5-4e6a-9f09-e1d2895969b3 at linaro.org/
> 
> Simon seems to think that his arbitrary *implementation* of a boot flow 
> is the only correct design, and there is no other usecase where 
> something else would be desirable.
> 
> After many repeated discussions with the same themes (and having 
> witnessed many of yours) I struggle to see Simons engagements as 
> anything other than bad faith, particularly when it's so hard to pin 
> down what the technical disagreements here actually are.
> 
> The patches in Simons U-Boot fork all appear to be either picked from 
> the list (often earlier versions that what actually made it upstream) by 
> other folks or his own patches that have been rejected for totally valid 
> reasons that he doesn't seem to want to get into good enough shape to 
> upstream.
> 
> You have repeatedly and publicly explained what it would take to get his 
> features merged upstreamed, and to be honest I think you have offered 
> him far more grace than other people in your position would.
> 
>>
>> With respect to voting, would anyone volunteer to run a poll from
>> https://civs1.civs.us/ (which is used by the Yocto Project /
>> OpenEmbedded and likely other FOSS projects/communities) ?
> 
> Maybe rather than this we could form a U-Boot board (via voting) and 
> this board would be responsible for managing the project and associated 
> resources, having and enforcing a code of conduct, etc etc.
> 
> There are various organisations which can help with this like the Linux 
> Foundation, NLNet (I have experience with this from postmarketOS) and it 
> would give the U-Boot community a way to be represented when it comes to 
> difficult situations like this as well as provide a way for the project 
> to grow sustainable as it increases in scope.
> 
>>

-- 
Casey (she/they)