build slaves: deb8 + deb9?

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.org
Wed Nov 1 14:56:31 UTC 2017


Hi Neels,

On Wed, Nov 01, 2017 at 02:48:27PM +0100, Neels Hofmeyr wrote:
> We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has
> also deb9 set as build slave to test.
> 
> I'd move over to deb9 now and no longer build on deb8.
> What do you guys think, should we build on both deb8 and deb9?

I don't really care all too much, but I am wondering why we are changing
a "known working" system.

In the end, we are providing packages for Debian >= 8 and Ubuntu >= 16.04.

Debian 8 is officially supported until June 2018, and Debian LTS will support
it until April 2020.  I would argue that the we provide Debian 8 builds
at least until June 2018.

That of course doesn't determine where we do the build testing before a patch
is merged, but in case we start using features not available on Debian 8, we
will then only find out once the nightly packages are built, as opposed to
before the patch is merged.  OTOTH, there are some more interesting warnings
generated by later gcc versions in later distributions.

All in all, I don't have a strong opinion one way or another.  But I am arguing
against change without a clear reason/purpose.

For example, if the new Debian 9 build-slaves were automatically generated by
ansible or Dockerfiles, then that would be a strong argument to migrate, as we
could much more easily scale if later needed with such a setup.

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)



More information about the OpenBSC mailing list