[PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

[Tom Rini]

On Wed, May 15, 2024 at 09:29:41AM +0200, Jonas Karlman wrote:
> Hi Tom,
> 
> On 2024-05-14 18:42, Tom Rini wrote:> 
> > git-subtree-dir: dts/upstream
> > git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> > ---
> > This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> > -next branch. To test these changes yourself locally, either use my
> > "WIP/14May2024-next" branch or run:
> > ./dts/update-dts-subtree.sh pull v6.9-dts
> > yourself locally. I intend to wait a few days to apply this to -next, to
> > give people time to test.
> > 
> 
> There are currently more boards/SoCs that use OF_UPSTREAM in master
> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
> Next dts/upstream sync will probably be good to do together with a merge
> of master into next :-)

Yeah, with -rc3 I'll pull that in to next. And I did this sync now since
Quentin reminded me on IRC about it. The massive CC list comes from
using qconfig.py to see who enables it, and then a quick one-off to get
a list out of get_maintainers.pl.

> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> probably be released shortly after U-Boot v2024.07. So will next sync be
> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> U-Boot merge window?

So, I need to put something in to doc/develop/process.rst about when the
full dts/upstream resyncs happen, and where. The plan currently is every
Linux kernel release gets pulled in, and master or next depends on if
the -next branch is open (which is with -rc2). This should give us the
most time to get changes tested, while minimizing drift away from
upstream sources. This is also because, and related to, that I try and
make sure that nothing breaking comes in to master once next is open,
and so if a board maintainer has time to test things at -rc3 or what
have you, it should still work in the release proper. More testing is
always great, but given our release cadence and generally predictable
schedule, I am hopeful this provides the best trade-offs in terms of
time demands on board maintainers.

> Linux kernel typically have all major DT changes in -rc1 and fixes in
> later -rcX, so for next branch I would suggest an early sync to a
> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> gets released. That should give more time for testing, migration and
> cleanup using v6.10 DTs in time for a 2024.10 release.

The issue in my mind is that we just don't have a lot of people with
time to test things in U-Boot. So I'd rather avoid possible broken
upstream and then fixed later upstream problems. And having done it now,
I can also say it's really easy to use dts/update-dts-subtree.sh so if
someone has time they can do that locally.

-- 
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/20240515/cbe7a79f/attachment.sig>