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
signature.asc
Description: PGP signature
