> * 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
