msgb_wrap_with_TL(): the hallmark of wrong choices made
nhofmeyr at sysmocom.de
Tue Jan 22 02:00:31 UTC 2019
I think we all agree that what happened with the msgb_wrap_with_TL() is a prime
example about how absolutely *not* to do things.
This makes me want to rewrite libosmocore history.
After all the naming / API duplication mistakes around msgb_wrap_with_TL(), the
final state I am trying to finish my day to is that the osmo-msc and openbsc
master builds remain broken, while patches to fix that are idling on gerrit
with a commit log summary that mentions neither that they fix the build nor
that they are related to msgb_wrap_with_TL().
All this happens with a new release tag on libosmocore, which was tagged to
include a commit that is supposed to fix things instead of break them...
Let's try to avoid this kind of series of events in the future.
* Separate function definitions must not have identical names.
* This applies both to the master HEADs as well as throughout entire API history.
* Especially functions moved to another source tree *must* change their name.
* Such API changes in libosmocore should be tested with "all" depending programs.
* API fixes in libosmocore should ideally build with both past and future
versions of depending source trees, i.e. should not need a matching patch in
the other source trees.
* When a commit breaks the master build in depending programs,
* clearly mark that so in the commit log and/or gerrit comments, so it is not
merged on its own by accident.
* the author should not go away until either none or both of them are merged.
* Similarly obvious, avoid pouring water on burning oil.
Sure, we all make mistakes every now and then.
In this case we made a few more :P
I spent time now to merge fixes to the master builds instead of going to
sleep... (I hope I'm not adding mistakes to the minefield, though.)
Not sure what to do about osmocom-bb. It has lots of implicit function
definition warnings, only one of them is:
gsm480_ss.c:441:3: warning: implicit declaration of function ‘msgb_wrap_with_TL’
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the OpenBSC