[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]