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

[Remi Collet]

Le 23/02/2015 18:44, Honza Horak a écrit :
> 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

Question about NEVR

The NEVR (in the spec) will probably be the same in the devel phase
(git/sclo) and after (git/rpms).
Isn't this going to be a problem ?
Does the %{?dist} need to be different ?

I think Koji will not accept a build with the same NEVR.



> 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?

+1 for a single repository, else it will be a nightmare for use of
dependent collection (ex php55 / httpd24)

> 
> 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. 

EPEL build against RHEL, so should build against RHSCL.



Remi


> 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
> 
> _______________________________________________
> SCLorg mailing list
> SCLorg at redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg


-- 
rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team
GPG Key: 0x29F16A18
Fingerprint: 5A0E 6F54 D94D 5732 69EE  E3FF 614A 6905 29F1 6A18