Hi,
I've added a new wiki page with an overview of the git infrastructure we
now have, to help developers choose the right one when e.g. working on
the jenkins scripts.
I saw that the Gitea wiki page also explains the mirrors, but IMHO it's
useful to mention it in this overview as well.
Best,
Oliver
On 30.08.22 19:26, Harald Welte wrote:
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.
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?
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte