Re: [CentOS-devel] Notes from CERN pre-dojo

On 23/05/18 08:07, Sandro Bonazzola wrote:

2018-05-18 11:51 GMT+02:00 Sandro Bonazzola <sbonazzo@redhat.com mailto:sbonazzo@redhat.com>:

2017-10-21 12:27 GMT+02:00 Rich Bowen <rbowen@redhat.com
<mailto:rbowen@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