I have created a fresh osmo-msc repository as a copy of openbsc.git, and pushed the first few patches for gerrit review to move to our "new" Osmocom CN: https://gerrit.osmocom.org/#/q/topic:vlr
As suggested before, osmo-msc will see code review and patches merged for VLR, 3G and AoIP, and so will form the basis for creating osmo-bsc, osmo-mgw and osmo-sgsn, as distinct repositories replacing the current openbsc.git.
All further development happening in openbsc.git from now on will have to be applied to the new repositories later. Keep that in mind, and maybe postpone larger conflict prone efforts for later.
The review process could take some effort. Some of the commits are one collapsed commit of fairly large development efforts. Normally, commits should be small, but in the case of completely refactoring an entire section of the code (VLR) or adding a completely new feature (IuCS, AoIP), it doesn't really help to see incremental back-and-forth changes with intermediate errors and fixes. I decided to collapse the errors with their fixes, and to save the effort of logically plucking apart the large commits, since they anyway only make sense as a whole. If necessary for review, we can still do so.
Despite the mass of changes, please do look closely. Parts of the new code have possibly been hacked up in a preliminary fashion and were forgotten to implement properly later -- this will become our new Osmocom master branches, the stable releases and our main development arena, so do apply your scrutiny and let's fix early what we can fix now.
The other repositories (osmo-{bsc,mgw,sgsn}) also exist already, and I am preparing to make them work as separate entities after the code review, on respective neels/split branches.
Each fresh repository contains the *full* openbsc.git history.
The option of relying on grafts to include the old openbsc.git history when needed has been mentioned, but so far was more or less turned down. It is still possible to change that. The openbsc.git history is about 9 Mb -- not too large, so IMHO best to keep it with each separate repos to ease log browsing, git blame and so forth. OTOH, we have it four times, which makes 36 Mb of duplicated history. If anyone still prefers a flat snapshot migration with a wiki page describing how to graft in the old history, we may discuss and change that.
No branches have been migrated except the current aoip development branch that is going to become the new master.
All tags are included, except: the signed '0.1.2' openbsc version tags are replaced by 'openbsc/0.1.2' tags pointing at the same revisions, so that we don't confuse them with the new version tags in each new project.
Preliminarily, the last openbsc.git master has been tagged as version 0.0.1 in order to get *something* out from git-version-gen, useful for referencing a version of the new libosmo-mgcp library in osmo-{msc,bsc} configure.ac.
We still need to decide whether to start versioning afresh or continue from the openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice would be to bump the major and start from 1.0.0 in each new repository.
~N
On Wed, Jul 12, 2017 at 11:17:56PM +0200, Neels Hofmeyr wrote:
No branches have been migrated except the current aoip development branch that is going to become the new master.
Please open a redmine issue about performing thorough branch review (after all new repos exist and are filled) on the old openbsc.git to see which branches still contain interesting bits that we want to pick into which of the new repos. I think that's quite important.
We still need to decide whether to start versioning afresh or continue from the openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice would be to bump the major and start from 1.0.0 in each new repository.
I would start with 1.99.0 or something like that for now and aim for tagging a 2.0.0 release once the entire transition is done.
On Thu, Jul 13, 2017 at 09:08:55AM +0200, Harald Welte wrote:
Please open a redmine issue about performing thorough branch review (after all new repos exist and are filled) on the old openbsc.git to see which branches still contain interesting bits that we want to pick into which of the new repos. I think that's quite important.
https://osmocom.org/issues/2363
I would start with 1.99.0 or something like that for now and aim for tagging a 2.0.0 release once the entire transition is done.
1.inf.0 ;) Seems a bit artificial but it does make sense to talk about a version two when the transition is done.
~N