RFC: Getting rid of FreeBSD build testing

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