libosmocore development flow

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)