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, >> cool! Do you have an idea of how we could automatically update our >> jobs based from this? A job that triggers on gerrit post-merge events (osmo-ci) would be my preferred choice. It's more elegant than polling and every merged change will be applied in seconds/minutes. Moreover, this job could also trigger "update-osmo-ci-on-slaves" job as suggested by Max if a change in the scripts/ folder has been introduced. Another topic to discuss are the credentials. The JJB allows to declare them in a file or pass them while invoking job creation. Would it be "okay" to store them on node(s)? Another way is to declare credentials in Jenkins global configuration and use the 'mask password plugin' to no show them in the console log. Furthermore, a dedicated user with precise permission to deploy jobs is preferrable. What is your opinion? >> Not on purpose but depends on when we created the job? Max already commented on gerrit that this is probably time related and that the "latest and greatest" version should be used everywhere. >> I don't think we want to verify drafts, we rarely use them anyway Okay, then 'draft verification' will be removed from the YAML file. >> On purpose. E.g. when executing tests that listen on a UDP/TCP/SCTP >> port we can't run them concurrently unless the ports are randomized >> or somehow virtualize them. In the case of concurrent builds we know >> we either don't run system tests or we run them in docker. Ah true, then the current YAML should be sufficient as it allows each job to define whether concurrent builds are allowed (default: false).