Miscellaneous Projects » Core testing infrastructure

laforge wrote:

The first odd part is that we have this repoistory in gerrit, whcih is wrong. I'm not sure if we can remove it from gerrit somehow. If we can, we should.

1- We have to keep our own fork in order to have the Osmux patches.
2- Github doesn't make sense since the upstream is in gitlab.eclipse.org anyway.
3- We can move it to our gitea if you want, but I'm not sure what do we win with doing that move (I probably created it in gerrit due to review being better?)

The second odd part is that we are changing the whitespace/formatting of upstream projects, see
[...]

All this leads to, IMHO, is potential clashes/merge problems when both upstream and our code change. So let's avoid trying to change upstreams coding style.

This formatting change has already been merged upstream a while ago, I submitted it in the same PR as "BSSAP_Types.ttcn: Add missing IEs for CommonID" commit, so it shouldn't be a problem.

We have one patch (osmux related) which doesn't make sense in upstream. So this means we keep a fork of upstream (on gitea.osmocom.org or github.eclipse.org) with that patch.

ACK, that would be gitea or gerrit as per my previous comment.

I just submitted a merge request containing VGCS/VBS related updates, see https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolModules.BSSMAP_v11.2.0/-/merge_requests/3

So once that is merged, please rebase the OSMUX patch on the (then) upstream, and drop the whitespace patch. Last, but not least, the reference in our deps/Makefile should be updated.

ACK, I will do the rebase once that patch is merged. I'm personally fine with keeping our fork in gerrit, but I'm also fine changing it to gitea if you think it's better, just tell me.

IMHO the best way would be to have the fork on gitlab.eclipse.org. This is where anyone else interested in titan / ttcn3 will easily find it, and this is where we can create PR for those current and/or future patches.

This was the idea of the gihub.com/osmocom/titan.* repositories. We could all push our branches there, and create PR.

The problem is, that on gitlab.eclipse.org, we (as a non-eclipse member) cannot create groups or organizations (like "osmocom") and hence only individual developer accounts exist. This makes it hard to keep "group maintained forks" like ours close to the upstream :(

As a workaround, we could now create an "osmocom" user and add all our ssh keys to it, so we can all push to repositories of that user. Not great, either.

So the fall-back is to go anywhere else, and that would be gitea. Gerrit should really only be used for stuff we maintain ourselves, i.e. official osmocom projects.

I think I will be able to remove the BSSMAP repository in gerrit myself when we are fulled moved to using the gitea one, by using:
https://gerrit.osmocom.org/admin/repos/titan.ProtocolModules.BSSMAP,commands and in there pressing button "Delete Project".

Whoever, I'm wondering what's the expected workflow to add new patches (not for upstream, or WIP to be merged in upstream) in gitea. Ideally we'd want to push to master whatever we see it's new in upstream, but I'm currently unable to push stuff in there due to lack of permissions. Only way I have to push stuff there to master is to submit patches to gerrit, get them merged in gerrit UI and then let the mirroring happen.
So laforge please provide feedback on your expected workflow there, I probably ended up creating gerrit repo at a time to circumvent the scenario I'm describing.

pespin wrote in #note-6:

I think I will be able to remove the BSSMAP repository in gerrit myself when we are fulled moved to using the gitea one, by using:
https://gerrit.osmocom.org/admin/repos/titan.ProtocolModules.BSSMAP,commands and in there pressing button "Delete Project".

possibly. There's also a delete-project command available via ssh.

Whoever, I'm wondering what's the expected workflow to add new patches (not for upstream, or WIP to be merged in upstream) in gitea. Ideally we'd want to push to master whatever we see it's new in upstream, but I'm currently unable to push stuff in there due to lack of permissions.

This is likely due to the situation that it was created as a pure mirror.

So laforge please provide feedback on your expected workflow there,

There is no real workflow expectation. In the past, we simply pushed fixes to an osmocom fork (wherever it might be) and then sent PR upstream.

If you want, you can follow the gitea PR model, if you think the kind of changes are more than just obvious fixes or simple additions. However, without manually adding reviewers, I doubt many people would notice.

I probably ended up creating gerrit repo at a time to circumvent the scenario I'm describing.

I doubt it. The gitea repository was most likely created at the time when all of the cgit+gitolite repositories (mirroring gerrit) were migrated over. All of those mirrors had to be manually created at any time in the past and still today.

I've added you to the "owner" role of the gitea repo, this should allow you to change it from a mirror?

Just to clarify again: in this repository, we have 1 extra patch which will never be merged in upstream and always need to be kept on top of upstream master (osmux related patch).

laforge so iiuc you suggest that when there's new patches upstream, we use the PR system of gitea to submit and get them merged in our fork? That IMHO doesn't sound like a good idea, given that we have our own patch (not for upstream) on top of upstream's master. Doing (as I understand) you suggested, would mean we would be merging using the gitea UI new upstream commits on top of our patch.

I think the desired way here is to have our patch (force-)rebased on top of newest upstream all the time, to have a clean upstream history with our changes always on top.
And for that, I'd have to be able to push to the master branch of gitea directly (force push), which afaik I can't do.

So, getting rid of gerrit I see 2 options here:
1- Always use the gitea UI PR (messy history)
2- Being able to force push to the master branch in gitea repo

Between 1 and 2, I'd go for "2". I expect now that I am an owner of the repo that I should be able to tweak the repo config to be able to change permissions to push to the master branch?

Let me know your preference here laforge .

I took the forward back as "do option 2".

• I converted gitea repository (pull mirror) to a regular repo with "Convert to Regular Repository" GUI button.
• Deleted gerrit repo.
• I rearranged the branches in gitea repo:
  • Updated new master to follow upstream master
  • Created a new osmocom/master which hill be rebased on top of master and contain our extra patches, and which will be used by osmo-ttcn3-hacks.git
  • Kept old master hashtag (used in osmo-ttcn3-hacks) as a branch "pespin/master-old" until following patch is merged:
    https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34823 Makefile: Update titan.ProtocolModules.BSSMAP to new osmocom/master branch

Once the patch above is merged, I can delete the pespin/master-old branch and be done with it.

Merged, closing.