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

[Tom Rini]

On Mon, Jan 27, 2025 at 04:40:21PM -0600, Tom Rini wrote:

> Hey all,
> 
> It's release day and so here's v2025.04-rc1. For a -rc1, I think we're
> in fine enough shape. The next window won't open until after -rc2 so if
> you have some outstanding patches that you think should be merged to
> mainline for v2025.04 please speak up (or for custodians, send a pull
> request).
> 
> As I mentioned elsewhere, I've scheduled a video call tomorrow at 9am
> -0600 and the calendar link is:
> https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N280N2tlcXE3aDVtbjlicnNkcm82YnA1bDAgODliZTdiODEzMTM2YmVjMDZhODNkZTRkYTU5NzQ1ZjBhYmQxMWMxYjgzNjA2MWFlMDZjMWM3ZGJjZDE4ZGY0MUBn&tmsrc=89be7b813136bec06a83de4da59745f0abd11c1b836061ae06c1c7dbcd18df41%40group.calendar.google.com

If anyone who couldn't make it has feedback about the time, please speak
up.

> and I also send the meeting invite via Google to the mailing list. I
> plan to do these regularly, post release and depending on reception the
> time can be adjusted or perhaps duplicate meetings held.

Here are my notes from the call. Anyone who was there should feel free
to send any corrections / updates. Thanks!

- Introductory remarks from myself.

- Michal Simek brought up the "SPI issue" that we had in testing
  v2025.01. He reiterated that it was tested on AMD hardware but only
  there as it's what they have access to. Ilias Apalodimas is trying to
  setup access to testing on Linaro HW, and has been for a while so this
  is still ongoing. Ilias noted in response to my concern about HW
  longevity that SPI NOR should be fine to test on, but that SPI NAND
  might need to be tested only weekly or similar. Michal noted Love
  Kumar posted the SPI tests that AMD uses. He agreed that weekly
  running might be OK, but they (and other HW vendors likely) have
  plentiful HW access, for their own at least and so wearing out a
  component isn't a concern. Finally, Michal noted that they want to get
  their HW working and can isolate the code as needed to not break other
  platforms.

- This segued in to Ilias noting that we have the general problem as
  well of getting things tested. Ilias asked about perhaps being strict
  at -rc1 instead of -rc2, just like the Linux kernel. Would people test
  next more if it was required to be used more? I said I was unsure as I
  had thought that I had been good about being strict with the -rc2
  cutoff in 2024, and the problem being a lack of testing of the next
  branch in general. Nishanth Menon talked about what TI tests as well
  (and showed some graphs/etc), on the topic of can we get more broad
  testing run. Ilias noted there's some outstanding patches that will
  let arm64 boot and run an OS image via dram, and this could help
  expand functional testing. Nishanth noted there's many testing
  frameworks in use, noted using a common test framework would be good,
  and that while we have pytest it's not been able to be integrated to
  their framework. Michal Suchanek suggested moving our pytests to UT.
  I asked how do we handle FS tests for example? The answer is that we
  would have to create the images outside of the testing framework in
  some manner and tests will expect them to exist. I suggested it would
  be good to see someone convert some of the more complex tests to UT,
  and we could use the Dockerfile to create the required images as to
  not have to rely on unknown binary files. I also noted that Simon
  Glass has noted a number of times that pytest is much slower than just
  running UT for a given set of tests. Ilias noted that using pytest is
  a bit of a hard learning curve. Ilias talked about how his TPM testing
  works, including using a VM to boot an OS and check the TPM output. I
  talked about how this could work with pytest as well. Nishanth was
  saying that in terms of a framework to enable the community to do
  tests, the kernel community seems to be ahead. He sees 3 key things in
  testing frameworks which are, the capability to do distributed
  testing, scale up from testing at the developer's desk testing to
  testing in corporate farms, this means having reference builds
  available and moving to a pull not push methodology and a centralized
  reporting system. It is a bigger, but tangential problem of scaling
  and standardizing testing. Ilias noted that some of those are
  orthogonal. Michal Suchanek said this is where testing diverges. I
  noted a reason for pushing for Labgrid is kenelci uses it and in turn
  this could be a good window in to existing hardware farms, Michal
  Simek noted problems with getting corporate IT to allow labgrid even,
  and this can require a separate lab. He suggested getting common
  reporting of common testing would be good and gave the example of
  being able to record the commands and results used in AMD testing
  environments. I mentioned perhaps saving/reporting pytest xml? This
  can be viewed in the pipeline page of a recent build (artifacts aren't
  kept for too long due to storage needs).

- This had a short follow-up with Ilias asking about if we can do
  sandbox tests on arm64 hosts in CI and I will follow up to enable that
  as the patches look to have been merged.

- Michal Suchanek asked about building 32bit sandbox but doesn't have
  time to look in to this right now, will file a gitlab issue instead so
  it's not lost.

- At this point no new topics were raised and I thanked everyone for
  their time and contributions and reiterated we'll have a meeting again
  in two weeks at this time, post -rc2.

-- 
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-board-maintainers/attachments/20250128/3f7132b4/attachment.sig>