can we start with:

chromite/build

chromite/ci

then as it makes sense, move scripts into the respective dirs and use owners to manage files in the transition

you want to move code under build/ and ci/ dirs ?  what all did you have in mind for moving ?  just scripts/ ?

i worry that moving around chromite.lib.xxx paths will be very disruptive.

Sorry for the brain dump, but...

I've definitely been thinking about this quite a bit as I've been porting things over. I was thinking about starting with splitting the scripts dir itself into categories, like chromite/scripts/build and chromite/scripts/ci, but leaving the symlinks in scripts/. It does make it somewhat confusing since you have to find the script in a respective subdirectory, but it keeps the current scripts "api" completely intact while providing a clear distinction on the implementation side, and leaving the top level namespaces open for things down the road.

Another thing I'd like to do long term is to simplify the scripts themselves a ton, turn most of them into a CLI entrypoint for the API that just parse and translate arguments and then call the functionality in lib or wherever. For lack of a better term, true "one-off" scripts can and should have their logic in the script itself, but there's also a number of places at least in lib, cbuildbot, and scripts itself that import scripts modules. IMO it's just a poor policy to have CLI entry points used directly, internally like that, a path over an import graph should basically get trapped in lib. I'd also lean towards the true one-off CLI scripts and the API's CLI entry point scripts be further subdivided to make it easier to enforce how much and what type of logic is put into the scripts. I mention it mostly because it might be something worth starting on if we're digging into any of the scripts that are currently imported somewhere else anyway.

I think my preferred end state is one that would have something like `cros`, `build`, and `ci` commands that encapsulate developer workflows, the build api, and the ci api respectively, and then maybe just have the one-off scripts alongside them. The `cros` command definitely has some performance problems though too, since it basically imports a huge amount of the project and incurs a good deal of overhead in the process. I'm sure there's a good solution to this, but with all the packing and moving, I've not been able to look into this enough yet to start formulating any good suggestions for how to get there.

I also have a lot of thoughts on lib/ that I haven't been able to really think through and condense into anything useful yet, but I do find the experience using it as a new developer confusing and frustrating. I think the OWNERS files will help short term, and a longer term goal of refactoring some of the larger files and reevaluating the organization will be a good start, but I'm not convinced yet that that'll be sufficient.

sgtm