libosmocore development flow

Hi! Andreas has asked me about this, and it might be interesting to a wider audience, so I've added the information to the wiki at https://calypso.gnumonks.org/trac/wiki/libosmocore Here's a copy of what I wrote there: == Development Cycle == As we are still developing the GSM protocol stacks on the network side (OpenBSC) and phone side (OsmocomBB), every so often there is a need to add some new code to libosmocore. Even worse, we sometimes need to break the API and ABI of the library. However, by keeping libosmocore in a separate git repository, we run into one problem: Checking out an old version of e.g. OpenBSC or OsmocomBB will result in failed builds, as we don't remember which old version of libosmocore was required. This makes debugging and things like git bisect very hard to impossible. In order to solve this problem, we use [http://github.com/apenwarr/git-subtree git-subtree] to import the full libosmocore.git repository into OsmocomBB. This way, we ensure that there is always a compatible version of libosmocore inside the tree if we check out old OsmocomBB versions from git. === Making changes to libosmocore === '''NEVER COMMIT CHANGES DIRECTLY TO osmocom-bb.git:src/shared/libosmocore''' Instead, use the following process: 1. make your changes to your local copy of libosmocore 1. test them together with OsmocomBB and OpenBSC 1. test if libosmocore still builds for both host and target (ARM) 1. create a ''diff'' of your local libosmocore changes 1. apply that diff to the libosmocore.git repository 1. use the script in osmocom-bb.git/src/shared/update-libosmocore.sh (uses git-subtree) to import your changes from libosmocore.git 1. test + commit your OsmocomBB changes that depend on the newly introduced code to libosmocore It is important that the steps are followed in the order state above to ensure consistency of our repositories Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)