CentOS Contributors Day, CERN
Thursday, October 19th, 2017
09:00 multiarch CI status
09:30 cross-SIG CI
10:00 workflow/process for deprecating SIG contents
10:30 allow SIGs to have separate accounts for build bots
11:00 Manage CBS multiarch at minor release ; quicker access to packages than distribution does, delegate more (i686?), etc...
11:30 OPEN FLOOR, work/hack session.
12:00 LUNCH
14:00 - 15:00 Datacenter tour
16:30 - 17:30 ATLAS experiment
Topics proposals:
- multiarch CI status? (Scheduled)
- cross-SIG CI ? (Scheduled)
- workflow/process for deprecating SIG contents. +2 (Scheduled)
- allow SIGs to have separate accounts for build bots. +1 (Scheduled)
- Manage CBS multiarch at minor release ; quicker access to packages than distribution does, delegate more (i686?), etc... (Scheduled)
- (mrunge) a kind of work session (?) if there is anything to be done/fixed "right now"?
- Building embargoed content
Notes:
Introductions
Multiarch CI (Haikel)
- no automated ci for all platforms
- if you're using CI, please subscribe to ci-user-list
- ppc64(le) machines are available, but request is manual right now.
- aarch64 boxes are small, community donated. Power-capacity is way bigger
- use cico client for interaction wih CI system
- suggestion to use zuul instead of jenkins for managing job queues
- AI on alphacc: add template for requesting sync to buildlogs to mention architectures etc...
Cross sig ci (Haikel)
- sig start depending on other SIGs, (multiple examples given)
- question on how to test pre-released packages
- define a matrix for SIGs depending on each other trigger tests - start email thread on ci-users list, create dependency graph from centos-release-*
- CI and CBS meeting on Mondays on #centos-devel
- CICO statistics are partially available through CentOS Zabbix instance
Workflow/process for deprecating SIG contents (mrunge)
- Historically we do not delete content ever. But we can move it to the archive/vault, and stop distributing it by default
- reasons to remove packages from the repository (move to vault.c.o):
- newer package in the (base) release
- dependency not needed any more from a newer release of your package
- end of life for versions (centos-release-gluster with per-version repositories)
- need a workflow for deprecating/removing a package
- SIGs are for experimentation - it's not for the distro to tell them how to run their process.
- single package removal by untagging - also needs update to KB's sync script
- whole repository removal by filing a bug,
Allow SIGs to have separate accounts for build bots
- separate user accounts from "bot" accounts for security reasons
- [proposal] have an email alias (not list) per sig for the bots, like sig-<bla>@
centos.org pointing to the SIG's chair
- [proposal] SIG chair must request or approve email alias requests/ ACO account creation sent to CentOS Board chairman
Package Signing
- SIG chairs should request feedback/insight into the package signing process --> KB
- have keys been generated securely (known bugs in package versions that make less secure keys?)
Sig request for sig specific git
sigs would like to use centpkg / lookaside, build direct through git to koji
Fabian to evaluate git solutions and report back to sig chairs.
mrunge has volunteered to be the "guinea pig" of the new system
Manage CBS multiarch at minor release ; quicker access to packages than distribution does, delegate more (i686?), etc...
- pre-CR buildroot for koji?
- does any SIG build against c7/i686? No, probably not
- For 7.4 building all the Alt-Arches took additional time, thus delaying the release. There is work being done to improve this for future releases
- is it possible to spread the load for contributors for building on alt arches?
Other topics
* Building embargoed patches
- current practise: build as soon as the embargo is lifted - wait for sign+push to mirror
- improvements possible for signing packages faster
* Board requirements/policy around SIG status?
- SIG chair missing: SIG may elect a new a chair and notify board
- inactive SIG members are disabled after some period.
- Define sane defaults in the SIG startup guide as a baseline (Patches welcomed!)