- automatic build verification, etc. makes sense to operate on the "root" repo of a given project (gerrit in most, gitea in other cases)
There is no trivial way to always get the "root" repo of a project (the one guaranteed to have no lag) -- a script now needs prior knowledge about what repositories live in gerrit. (Merely stating facts.)
- point git.osmocom.org at gitea.osmocom.org/osmocom/ ? (cgit.osmocom.org still works)
https://git.osmocom.org/foo/bar are HTTP 302 redirects to the respective gitea counterpart
ok, that's nice. Noting though that git://git.o/foo and https://git.o/foo end up in two different repositories.
https://git.osmocom.org/ are in fact HTTP redirects to the respective gitea URLs
This is interesting: if i use a https://git.o.o/ url i reach the gitea repos without knowing the gitea subdir. or, in other words, the nginx config for HTTPS git URLs is a mapping from a flat dir structure to the various subdirs.
If I follow that tangent, the https://git.o URLs to gerrit projects could redirect to gerrit, not gitea. Then the https://git.o nginx redirections would provide the lag-free "root" repos for each project, in a flat subdir structure.
- move gitea/cellular-infrastraucute/* to gitea/osmocom/* ?
What would be the point of that?
The reason to bring it up is that libosmo-abis, -sccp, -pfcp,... might also be considered cellular infrastructure. They seem to live in osmocom/ only because they start with "lib"?
The osmocom/* "organization" should IMHO only be used for stuff like libosmocore which is used by multiple projects.
So as soon as some other project starts using one of the cell-infra projects, the cell-infra project must be moved to "osmocom"? I'm just teasing to test the reasoning...
~N