This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgDear all,
Holger and I (plus later the sysmocom team) had a discussion about whether
we should continue to keep the FreeBSD build testing.
Right now, jenkins is set up in a way to test build of a patch on Linux
(currently Debian 8) and FreeBSD (currently 10.3). Only if it builds
and passes "make check", the patch gets the magical "+V" so it can be
merged.
While in general it's of course good practise to write portable code and
to test building on multiple operating systems, this adds quite a bit of
extra effort:
* patches every so often don't build on FreeBSD due to include header
differences or the like, requiring extra iterations of a patch
* the build takes longer time as the build matrix is multiplied by two
operating systems
* we cannot easily/safely migrate the way we buld to docker, as docker
on FreeBSD is experimental
Particularly during my recent OpenGGSN developments (IPv6) support, this
was a big PITA and I'm sure I spent more time in debugging FreeBSD build
issues than actually writing the code in the first place.
Given that we arr not aware of anyone using the Osmocom stack on
FreeBSD, the suggestion is thus to focus our available time on actual GSM
related features rather than fixing up portability issues.
So unless we receive significant complains as a response to this e-mail,
we will disable the automatic build testing for patches on FreeBSD.
This doesn't mean we will drop related code from our projects. We still
appreciate build and other fixes for other platforms, but those would
have to come as contributions from users on those platforms, rather than
something that's actively maintained and tested by Osmocom upstream.
If we want to extend build testing, I think it's more useful to have e.g.
ARM/Linux builds, or clang builds on Linux than the FreeBSD builds.
Let me know what you think.
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)