I spend some times last weeks trying to understand the structure of the codebase.
i believe it could help a lot to harden the modularity in this kind of situation.
here is a draft of the remap i have sketched :
./src <- julialang/julia-runtime
./doc/devdocs <- julialang/julia-runtime-doc
./base <- julialang/julia-stdlib
./doc/stdlib <- julialang/julia-stdlib-doc
./test <- julialang/julia-stdlib-test ?
./doc <- julialang/julia-doc
./src/support <- julialang/julia-libcshim
./src/flisp <- julialang/femtolisp
./deps <- julialang/3rd
./contrib <- julialang/sandbox
./examples <- julialang/examples
./etc <- ?
./ui <- ?
This help to spot well performing vs weak assembly.
A lot of good parts appears there. 3 weakness imho: lack of femtolisp test, runtime test, femtolist doc
We do not need absolutely to move on to git submodule yet. All these kinda of work could be simultate with proper subdirectories discipline. Next point should be to reflect the change in the make file.
We could later decide more simply where to plug bias
I’m still a newbie with the julia codebase and my viewpoint could be a rough approximation of reality for now.