On 23/05/18 08:07, Sandro Bonazzola wrote: > > > 2018-05-18 11:51 GMT+02:00 Sandro Bonazzola <sbonazzo at redhat.com > <mailto:sbonazzo at redhat.com>>: > > > > 2017-10-21 12:27 GMT+02:00 Rich Bowen <rbowen at redhat.com > <mailto:rbowen at redhat.com>>: > > Also, because it's in an etherpad, and is thus subject to > alteration or vandalization, I'll also put a copy below for > posterity. > > If there are any parts of this which are unclear to those that > weren't present, we encourage you to start a new thread per > topic for further discussion. > > Thanks! > > =================================== > > > CentOS Contributors Day, CERN > Thursday, October 19th, 2017 > > https://indico.cern.ch/event/660692/overview > <https://indico.cern.ch/event/660692/overview> > > 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 > - more detail on the multiarch page in the wiki (not able to > find it through https://wiki.centos.org/QaWiki/CI/Duffy > <https://wiki.centos.org/QaWiki/CI/Duffy> ) > - https://wiki.centos.org/QaWiki/CI/Multiarch > <https://wiki.centos.org/QaWiki/CI/Multiarch> > - use cico client for interaction wih CI system > - cicoclient multiarch support has been merged => > https://github.com/CentOS/python-cicoclient/pull/14 > <https://github.com/CentOS/python-cicoclient/pull/14> > - 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 > - to test against extras, SIG should provide tests to > t_functional from CentOS QA. Wiki page is located at > https://wiki.centos.org/QaWiki/AutomatedTests/WritingTests/t_functional > <https://wiki.centos.org/QaWiki/AutomatedTests/WritingTests/t_functional>. > git is located at > https://github.com/CentOS/sig-core-t_functional > <https://github.com/CentOS/sig-core-t_functional>. Results are > to be found at https://ci.centos.org/ (search for "pretest" for > results before package release and for "t_functional" for daily > tests) > - 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 <http://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 > - sometimes, there is a delay in package signing/sync to > mirror.centos.org <http://mirror.centos.org> > - 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 > authentication requirements to accounts.centos.org > <http://accounts.centos.org> > 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 > > > Any improvement on this topic since October? > > > Should I take lack of answer like a no? > I sent mails for all those topics and was hoping some momentum/reactions on those, but there was none, unfortunately, so yes, I consider that "no" seems the current answer for your question -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20180523/be28306f/attachment-0008.sig>