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/.
André Boddenberg dr.blobb at gmail.comHi Neels, >> In any case, I would like to include you in the discussion, >> and maybe you would also like to be involved in maturing the idea? Thanks and sure, I already excitingly read mails with similar topics like lxc and Jenkins YAML jobs. The latter will be commented soon. >> This line fetches the given URL (in this case the latest patch on that >> branch) and considers the docker image as unchanged if that URL shows the >> same as last time. As soon as a new patch shows, things are rebuilt. Great idea! So, the hourly/nightly jobs would "docker build..." instead of "docker run..."? Will there be one Dockerfile per each branch or is planned to use docker's "ARG and "--build-arg" to pass branch while building? Furthermore, the nightly package of libosmocore-dev confuses me, especially when thinking about gerrit jobs. How often are these packages updated? >> In this sense we could have docker images cascading on top of each other, >> adding individual dependencies and reusing identical states auto-detected >> by docker. All build steps would be in the Dockerfile. Afaiu images will be rebuild if a new patch is introduced. But who is invoking the rebuild when the parent or libosmocore-dev in the example have changed? Sharing same layer for "RUN apt-get install ..." command as shown in osmo-nitb-master and osmo-bts-master Dockerfile could be promising. But only if above mentioned rebuilding mechanism is smart enough to build only one image first so following will reuse its layer. In general I like the "move" towards docker compared to lxc, which does not provide something similar to a Dockerfile. On the one hand the described (free) benefits sounds really promising. On the other hand I am skeptic about the whole life cycle, which imo needs some external management as described to keep everything up to date. Additionally, every "docker run ..." command would need a "docker pull ..." before to ensure latest image from repository. I will definitely setup some build jobs on my Jenkins with those Docker images to get a better understanding. P.S.: >> I feel a bit bad for accepting your contributions, doing review and keeping you busy No worries at all! :)