Hi Neels,
On Fri, Aug 19, 2022 at 04:23:01PM +0200, Neels Hofmeyr wrote:
I guess it's a bit late, but do we really need categories on gitea?
I guess you're familiar with the work ongoing for multiple months in https://osmocom.org/issues/5397 ?
To clarify, we're referring to "organizations" in the gitea/github/gitlab context. At least to us in Osmocom, they serve multiple purposes:
a) logical grouping of repositories that belong together. Makes it easy to find related projects, and helps people who are just interested in one aspect, e.g. sdr or op25, for example
b) permission management. It's much easier to manage permissions of an "organization" rather than for each and every repository. Think again of e.g. the "sdr" organization: People like steve-m or tnt can autonomously create new repositories in that organization, give new developers permissions, etc. - this is what always used to require my manual intervention in the pre-gitea past.
Please note that even before gitea we had two orthogonal ways of grouping:
1) logical grouping in the cgit UI (based on a config file) 2) sub-directory grouping, like the erlang / smalltalk / cc / sub-direcotries
The new namespace in gitea cleans that up to some extent.
The simple world I would have expected:
git clone https://gitea.osmocom.org/libosmo-pfcp git clone https://gitea.osmocom.org/osmo-upf
that flat namespace only works via the old git.osmocom.org mirror, and only for those repositories that have been configured respectively.
and
works: git clone git://git.osmocom.org/osmo-upf
that's because this is not set-up/configured. It's questionable whether we still want to care about git://
fails: git clone https://git.osmocom.org/osmo-upf
this is due to the fact that https://git.osmocom.org/ are in fact HTTP redirects to the respective gitea URLs. And of course if somebody creates a new repository without adding such a redirect to the nginx config, it won't work.
While I'm at it: do we have a designated primary git place for Osmocom? De facto the answer seems to be: gerrit, except when it's not on gerrit.
The Osmocom project is more than the subset of projects/repos any single developer is working on. Some projects (around CNI) have chosen to use gerrit because it makes sense for them. Other projects have chosen not to, and I am certain we don't want to force every sub-project to use a certain tool.
Also, gerrit makes sense for projects with large number of changes, where the group of contributors is relatively static. I certainly understand why people don't want that for a project that receives <= 1 patch per month.
Because of the above issues, currently there is a wave of patches rolling out which edit build scripts and READMEs to change git URLs -- it feels wrong that this is necessary.
There are multiple overlapping topics:
* the change away from git:// to https:// should have happened a long time ago
* automatic build verification, etc. makes sense to operate on the "root" repo of a given project (gerrit in most, gitea in other cases), rather than a mirror which might lag "whatever the mirroring interval is" behind in time.
It seems the topic needs some clarification, and maybe it is still possible to simplify the git structures?
What exactly is the problem? How often do any of us have to create a new clone of a repo? I have my 100+ cloned repos lying around. Those that used gerrit before needed no update, and only those that used gitolite before *and* to which I push needed to update the remote URL. pulling/reading the old URLs continues to work, which is what was most important for me, given that this is by far > 99% of the git utilization.
- remove the layer of categories from gitea?
This is not how (gitea,gitlab,github) work.
- move gitea/cellular-infrastraucute/* to gitea/osmocom/* ?
What would be the point of that?
* osmocom is the umbrella project of *all* the projects * CNI is a subset of certain projects within osmocom
By renaming CNI to osmocom we'd introduce wrong terminology.
The osmocom/* "organization" should IMHO only be used for stuff like libosmocore which is used by multiple projects.
- point git.osmocom.org at gitea.osmocom.org/osmocom/ ? (cgit.osmocom.org still works)
Can you please be more specific what you are referring to? As stated, git://git.osmocom.org is a read-only mirror and https://git.osmocom.org/foo/bar are HTTP 302 redirects to the respective gitea counterpart
- keep cgit as the primary git place, gitea as users' playgrounds?
What is a "primary git place"? The developers working on the related projects inevitably will have to use gerrit for projects hosted there (to push pactches for review) and gitea for projects hosted there (to generate PR)
And for regular users, as I stated, nothing should change: * if they had a git:// clone, it continues to work (they can 'git pull' without any changes) * if thyey had a https:// clone, it contiues to work, likewise * if they do a first-time clone, they just copy+paste the URL from redmine or gitea. it doesn't really matter what's inside the copy+paste buffer
btw: By coincidence, today a person showed up on IRC expressing their enthusiasm that now with gitea finally they can send pull-requests to projects like rtl-sdr.