On Mon, May 05, 2025 at 05:34:58PM +0200, Simon Glass wrote: > Hi Tom, > > On Mon, May 5, 2025, 15:45 Tom Rini <tr...@konsulko.com> wrote: > > > > On Mon, May 05, 2025 at 02:58:06PM +0200, Simon Glass wrote: > > > Hi Neil, > > > > > > On Mon, 5 May 2025 at 09:06, <neil.armstr...@linaro.org> wrote: > > > > > > > > Hi, > > > > > > > > On 02/05/2025 04:50, Simon Glass wrote: > > > > > During a recent discussion with Heinrich we discussed why the hooks > > > > > are > > > > > kept in a separate repo. > > > > > > > > > > The amount of code is small, a tenth of the size of the recently added > > > > > lwip, just by way of example. Testing is a critical part of U-Boot and > > > > > one of the things that distinguishes it from firmware projects that > > > > > have > > > > > not kept up in this area. By having the tests somewhere else, we are > > > > > signalling that it is unusual, or difficult, or optional. > > > > > > > > > > The hooks mechanism also needs something of an update to take account > > > > > of > > > > > real boards in 2025. That will be much easier to undertake if the code > > > > > that test/py talks to is in the same repo. > > > > > > > > > > This series brings the hook files in as first-class citizens of > > > > > U-Boot. > > > > > > > > So this will definitely remove the ability to have test hooks out of the > > > > U-boot tree ? > > > > > > No, not at all. I think Tom had the same thought, but I'm not sure where > > > it > > > is coming from. You can of course put the hooks wherever you like, since > > > you have to specify the path for them anyway. > > > > > > >This is a major regression, and I do not want my test hooks > > > > to be in the main u-boot tree for plenty of reasons, the main reasons is > > > > that I need flexibility to handle my lab boards and I can't wait > > > > multiple > > > > weeks to have the hooks fixed in the main tree. > > > > > > > > This could be enhanced, but I agree with Tom, it's a bad idea to merge > > > > them in the main tree. > > > > > > Are there any other reasons, beside the misunderstanding here? > > > > I don't think there's a misunderstanding here. If I follow what you're > > saying, you want the hooks to primarily exist in the main source tree. > > Yes, of course someone could maintain them out of tree instead. But > > that's adding pain to that set of users. > > People maintain them out-of-tree today. They can simply keep doing so. > I am not sure what you are getting at here.
Yes. People use the tree, today. Likely pulling in changes and merging them to their local branch as needed. That's no longer possible if the repository goes away and instead is in the main U-Boot tree. Or were you thinking it would be maintained as a mirror of what goes in mainline? > > And I'm not sure what the > > benefit is to anyone else to move them in-tree. We're making the project > > CI path a tiny bit easier (but for what is also a small case) at the > > expense of all of the other cases. > > Did you see Heinrich's email? Yes, and I replied. > > If we must save two steps in the case of testing new changes for CI, we > > could add the u-boot-test-hooks repository as another git subtree. This > > would make it easy to test new CI changes at the expense of making it > > more costly (a git subtree resync) when we want to update the hooks > > repository. > > I don't see how a subtree would help though. It's not as if some other > project is using it, upstream of U-Boot. It would solve the problem of "need to test changes in CI easier" without breaking the regular use case of "separate lab infrastructure from the project". Perhaps the problem really is that configuring the hooks also looks for data that's in the hooks repository. But all of that said, this still feels like a step backwards. You don't put more projects in a single repository, maintaining and using multiple repositories is easy now, we aren't stuck in RCCS / CVS land anymore. Heck, the reason I point out subtree is that is how you manage these kind of problems. Even more so for parts of the code where it's easier to say that yes, multiple people can have write access. -- Tom
signature.asc
Description: PGP signature
