should we have a single git repository for every (compiled) tool?
Open, Needs TriagePublic

Description

This would simplify packaging and maintaining.

Example: https://github.com/apertus-open-source-cinema/misc-tools-utilities

davidak created this task.Nov 2 2017, 12:05 AM
davidak updated the task description. (Show Details)
davidak raised the priority of this task from to Needs Triage.
davidak added a subscriber: davidak.

In my opinion, no. This would just multiply number of repos, which increases difficulty of maintenance afterwards.

What would be the advantage compared to how we have it currently (multiple applications in one repo)?

  • 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.

Those are valid points indeed.

The disadvantage is that it make it really hard to get/keep an overview of the different software packages and where they below...

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!

BAndiT1983 added a comment.EditedFeb 19 2018, 10:25 PM

As the software grows, it maybe a good point in time to split it in sub-modules, so the things do not interfere. How would we split the things and keep track?

anuejn added a subscriber: anuejn.EditedFeb 19 2018, 10:28 PM

Yeah you are completely right! Axiom Firmware would be a much better name!
Moreover, I quite like the idea of having repos for each topic (like gateware, web-gui, daemon, configs, ...)