[ANN] U-Boot v2025.04-rc4 released

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250311/f88979f0/attachment.sig>