Hi Neels, On Mon, Aug 29, 2022 at 01:16:35AM +0200, Neels Hofmeyr wrote: > > * 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.)
If we'd write (or rather generate) a gerrit replication config file for all the gerrit-hosted repositories, we could switch the gitea mirrors of those repositories from pull mirrors to push mirrors. That way gitea.osmocom.org should be in sync all the time and could be treated as 'root' for both gerrit-root and gitea-root repositories. > > > - 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. that's correct, as git:// doesn't have redirects, and is probably not even supported by gitea. So if we want that backwards compatibility, it's yet another mirror. > 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. for legacy repositories, yes. > 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. I don't think we generally want non-developers to use gerrit to avoid it overloading at some point. I think it makes sense to separate the "publicly advertised repo" from the "internal repo used by active developers" > > > - 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"? Unfortunately libosmo-abis is needed by several projects that have nothing to do with abis (and hence CNI), like osmo-remsim, for example. The reason is our complex way of spreading around IPA multiplex bits over 3 different git repositories :( SCCP/sigtran is a regular ITU SS7 protocol not strictly tied to cellular protocols. There are other use cases, primarily in wired telepony. So the only one that's wrong is libosmo-pfcp. I'm sorry if I created it in the wrong organization :( > > 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... I think it's more whether or not the code inside the project implements something that is specific to cellular infrastructure or not. And that should be known from the onset and unlikely change at a later point? -- - Harald Welte <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
