On Mon, Mar 10, 2025 at 05:32:15PM -0600, Tom Rini wrote: > Hey all, > > So it's release day and I have tagged and pushed things out. This will > be merged to -next shortly. > > Continuing on with what I started after the -rc1 release, we had a call > today and the link was > https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N280N2tlcXE3aDVtbjlicnNkcm82YnA1bDAgODliZTdiODEzMTM2YmVjMDZhODNkZTRkYTU5NzQ1ZjBhYmQxMWMxYjgzNjA2MWFlMDZjMWM3ZGJjZDE4ZGY0MUBn&tmsrc=89be7b813136bec06a83de4da59745f0abd11c1b836061ae06c1c7dbcd18df41%40group.calendar.google.com > and once again this is the same time as the previous meeting. The > meeting details itself are: > https://meet.google.com/btj-wgcg-euw > March 11th, 2025. 9am (GMT -06:00) > > To join by phone: > https://meet.google.com/tel/btj-wgcg-euw?pin=1307528552322&hs=1
Again, sorry for the confusion about when the meeting was. It was today the 11th, and here are my notes. All errors are unintentionally my own. As a general note, to try and reduce confusion it was suggested and I will moving forward note that the calendar on https://www.u-boot.org/ has the meeting (and will show in local timezone) and just provide the direct link and time. - I noted that -rc4 was yesterday and we have one more rc before the April release. If anyone knows about regression fixes that are still outstanding, please speak up. On that note, Ilias noted that an issue recently was seen with small memory devices and EFI booting. It's likely a corner case that has always existed, and more debugging is required. If resolved in time and a reasonable fix, it should be included in the release. - I moved on to stating that I had been talking with the Software Freedom Conservancy (SFC) about the U-Boot project moving to be under their umbrella for various reasons, and introduced Karen Sandler and Bradley Kuhn, from SFC that had joined the call and asked them to introduce themselves and SFC. - After that, we had a few questions / answers and I'm going to briefly summarize them here. Heinrich asked a few things about where SFC is located and how that might impact the project overall. Karen and Bradley confirmed that SFC is a US organization, but also that where servers exist physically matters more than where the organization is, with respect to export control and similar. Comparing SFC to Linux Foundation (LF), as a matter of US law, SFC is a "501c3" charity which needs to act in the public interest whereas LF is a 501c6 trade organization. This in turn means that SFC focuses on projects run by communities rather than big corporations. SFC does things like try and help projects to organize themselves, and when they have money figure out how to spend that money to better the project as a whole. Projects are not required to bring in more money than their overhead to the project requires for example. Andre Przywara asked if there would be any day to day changes to the project, for example how FSF until somewhat recently required copyright assignment. Bradley noted that there would not be and that for copyright specifically, they prefer the model that U-Boot already has. I mentioned that getting back to the differences between SFC and LF for example, the statement LF put out somewhat recently about US sanctions and open source projects differs from the opinion SFC has there and that I found the SFC opinion to be much more developer friendly. Bradley and Karen noted that SFC has a further post on this topic being worked on currently. - I asked about new topics and Heinrich brought up the lengthy email chain between myself and Simon about speed of project development. As Simon wasn't on the call I didn't want to misrepresent him and his views and so tried to keep this somewhat brief. In sum, he and I have fundamental disagreements about the speed at which U-Boot should make changes. I believe we need to move slowly and deliberately and it's OK if migrations take quite a long time to complete because most people aren't testing every release, let alone every -rc. Heinrich asked if it would be helpful to document what migrations need to be done and what their deadlines are. I noted we have been doing some of these but some of the problems are that deadlines are years out, and then consequences another year out still, and I believe Simon believes this is too long. Heinrich brought up the example of bootstandard migration and I noted that yes, as the sunxi example shows I believe we have bigger problems there to resolve before we could set some deadline. - We had a small tangent about boot standard and upstream device trees and I noted that upstream schema is interested in taking what we have to offer, it's just a matter of doing it. The bootph- properties are a good example of how this has been solved in the past and can be solved moving forward. - Getting back to development speed, Andre noted this is side project for him and he doesn't have cycles for dealing with everything quickly enough sometimes. Taking a more "relaxed stand" makes sense for him. He does see this as something that Simon is very interested and invested in. - Heinrich noted it would be good for Simon to be on these calls and get feedback from the community on prioritizing tasks and similar. I agreed. - Ilias noted that with respect to how often / how many big changes come in per release, what a "big change" means needs to be defined. For example, the MMU changes he's working on, he did examine using the CPU uclass as Simon suggested, but then saw it's utilized on very few boards and so not useful for this feature. - I summarize the LED uclass as another example where he and I disagree. - Ilias noted migrations should be done by the introducer as much as is possible. I noted that Simon did that historically but was hoping more people would pick up and do them now. I noted that it's indeed hard and often thankless work to do those migrations blindly. - Ilias noted he's fine taking stuff that's in progress so long as it can all be logically and reasonably explained. - As Simon wasn't on the call, I wound this topic down at this point. - Ilias asked how the MMU feature he's been working on should be enabled once it's merged as it finds code bugs, but also those bugs lead to crashes. After talking with Andre a bit, he's going to try out a few different allwinner SoCs with a number of peripherals to see what falls out. I noted that it looks like the generic problems have been found and patches posted, so it's going to be a per-SoC thing next and asked if TI can also try it out on K3 platforms, once merged. - Heinrich asked if Allwinner D1 support will happen, and Andre said a number of people have asked but not a lot of developers. The ARM version of the chip is upstreamed, it's just the RISC-V side missing. Someone needs to step up and help on that side. Andre just lacks time. The next question is of how much long term interest there will be here as it could really end up as just a one time one-off. - At this point I said we should wrap up the call and Karen noted that if there's more questions about SFC people should feel free to reach out to them. I noted that I still owe making a dedicated email thread about this and would soon. - Heinrich asked if we would have a meeting two weeks after the release, during the merge window or not. I said I didn't know and Andre agreed it would be a good idea. So I will figure out making a one-off meeting for that. -- Tom
signature.asc
Description: PGP signature
