- a program is easier to find on github
- commit messages and issues are related to the one program
- we can configure a CI (like Travis/Gitlab CI) to test, build and package the program, needs a YAML file per repo (there you select one language and get the build tools)
- you can use git tags to tag releases
- it's easier to use git bisect to debug in which commit a bug was introduced
That are the reasons from my perspective. Like mentioned in the title, scripts that can just get copied onto the camera can sit in one repository.
I have to agree with davidak - and go one further:
From what I can see, a master build repository (with branches and tags) that pulls submodules from other project repos would be ideal. If done well, it would also allow a running system to update specific components instead of its entire codebase - which keeps the distro lean and healthy - and *probably* less prone to catastrophic update failure.
This kind of modularisation of the project into components allows various teams to focus on their respective part. From a workflow perspective, it also enables pull-requests to be approved by a greater number of people - which means if you don't care e.g. about the webserver you won't be bothered by a sprint constantly pushing to dev and making pull-requests to master.
Of course this also means that somebody / some people / some tests / some CI will have to have an absolute overview of how the components all fit together and be able to decide if release candidates from submodules can be integrated into the project as a whole - or if there is something missing.
For my part, I had my very first look at the repo today - and although it is pretty clear to me how everything works, it was also rather daunting. Especially because the "Beta Software" package title is also a bit misleading: there are boot configs, SOC vhd's, c++ api servers and php thrown in here and there. This package is more than just software!