[scl.org] Workflow for Software Collections (SCLs) in CentOS

[Honza Horak]

This proposal considers the following:
  * we want to provide stable SCLs rebuilt from RHSCL for CentOS users
  * we want to have a platform for upstream development for collections 
that:
    - will be part of the future RHSCL (same SCL name as in RHSCL uses, 
RH developers own those, others may contribute -- send patches)
    - have been part of RHSCL but will get some update eventually, so we 
want to test the fixes before applying in RHSCL
    - are not intended for RHSCL (those won't use "rh-" prefix [2], but 
should have some other prefix)


Some technical details of CentOS Build Service (CBS) at [3]
=============================================================================
There are several projects in centos distgit (http://git.centos.org), 
those two are important for SCL:
  * sclo -- code of testing packages, uses fedora layout (specfile and 
sources directly in the repository, no directories), building rpms in 
CBS only from srpm, final rpms are testing only (tagged into sclX-testing)
  * rpms -- code of stable packages, centos layout (specfile and sources 
in SPECS, SOURCES directories), building rpms in CBS either from srpm or 
from scm, possible to build official rpms (tagged into sclX-release, 
request signing and releasing)

There are two koji tags set for all collections for every elX version (X 
is 6, 7, ...el6, el7, ...):
  * sclX-testing: default tag where all built srpms are tagged into
  * sclX-release: only rpms built from scm can be tagged here (and will 
be signed)


Workflow schema:
================

     git.c.o       CBS         scl.org [1]
-----------------------------------------
   develop in
  sclo project
       |  \
       |   \
       |     build from srpm
       |     for testing only
       |            |
       |            |
       |     rpm tagged into
       |      sclX-testing
       |                   \
       |                    \
       |                    available in
       |                    sclo-testing
       |                        repo
       |
       |
  import srpm
   into rpms
    project
           \
            \
              build release
               candidate
                from scm
                    |
                    |
               tagged into
               sclX-testing
                            \
                             \
                             available in
                             sclo-testing
                                 repo
                             /
                            /
                 tag into
               sclX-release
              sign & release
                            \
                             \
                             available in
                             sclo-stable
                                repo


Description of the scheme above
===============================
Workflow during development phase:
----------------------------------
  * this part is valid for future RHSCL collections that (both net new 
and major update) are not yet available in RHSCL
  * contributors prepare new collection under sclo project
  * contributors build testing rpms from srpm
  * rpms are tagged into sclX-testing
  * scl.org [1] imports specific collections from sclX-testing

Workflow during maintainance phase:
--------------------------------
  * this part is valid for collections that are/were released
  * contributors prepare patches under sclo project to test them before 
applying (in RHSCL or non-RH stable SCL) -- fix smaller bugs, extend 
stable collection in compatible mode, generally maintain compatibility 
of the collection
  * contributors build testing rpms from srpm
  * rpms are tagged into sclX-testing
  * srpms are manually imported from sclo to rpms project @ git.c.o
  * contributors build official packages from scm and tag them into 
sclX-release
  * contributors ask for signing and publishing
  * scl.org imports specific collections from sclX-release and 
potentially also from sclX-testing

Specific for RH collections:
----------------------------
srpm can be automatically imported to rpms project or even to sclo 
project on errata publishing if maintainer wishes so


Some open questions
===================
Q: scl.org to provide a separate repository for each collection? or one 
repository for all collections in -testing?
Proposal: we can start with one common repository for all stable centos 
collections, the same we do in RHSCL?

Q: what about centos vs epel?
Proposal: if there are some packages that want to use centos collections 
in the future, epel should start to build above centos' sclo repos. That 
means the same collections don't need to be build again in epel. How is 
it done in other centos SIGs in case they provide the same components in 
epel?

[1] https://www.softwarecollections.org/en/scls/
[2] https://www.redhat.com/archives/sclorg/2015-February/msg00022.html
[3] http://cbs.centos.org

Honza