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

Re: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL



On 03/04/2015 02:13 PM, Honza Horak wrote:
On 03/04/2015 01:56 PM, Jim Perrin wrote:


On 03/04/2015 06:42 AM, Honza Horak wrote:

There is also another idea Remi suggested.. It's basically about having
3 repositories:

- centos-scl => downstream of RHSCL, same content, only for CentOS users

- centos-scl-devel / testing => upstream of RHSCL (we need to ensure
that NEVR in this repo < previous one) and perhaps additional packages
(for CentOS and RHSCL users)

- centos-scl-sig / additional / stable => package NOT in RHSCL. This can
be used by CentOS and RHSCL users.


I like this idea, but I'm not crazy about the name of the last one, as
it's not entirely clear what it is. I might suggest
centos-scl-sup(plementary). You guys are the SIG. These packages would
supplement what exists already.

This would be a good repo for the 500-odd perl module scl packages we've
been contacted about as well.

The workflow as proposed before only included two repos (collections
from 1st and 3rd were actually merged in one repo), which would mean
this 500-odd perl module collection would be included (after being
developed in scloX-testing) into scloX-release. And I'd expect the
prefix would actually distinguish it from rh-perl5xx collection.

My main concern with remi's way is how would we create collections
depended on RHSCL rebuilds? The collections are separated from their
essence anyway, so I don't see a strong reason to separate them into two
repos. With one common repo we'd also safe troubles with having one
repository enabled, while another is not (en thus seeing broken deps).

What are advantages of separate repos for RHSCL downstream and
additional-stable collections?

I got the idea about 3rd repo in the end and this is the new workflow proposal:
https://www.redhat.com/archives/sclorg/2015-March/msg00021.html

I'd be glad for any feedback..

So, having this changed workflow on my mind, the branches/tags set becomes more complicated... Let's see (using 'rhscl' for identifying collections that are part of RHSCL -- not sure how much it will confuse users):

final tags (and repositories):
sclo6-release
sclo6-testing
sclo7-release
sclo7-testing
sclo6-rhscl-release
sclo6-rhscl-testing
sclo6-rhscl-future
sclo7-rhscl-release
sclo7-rhscl-testing
sclo7-rhscl-future

build tags for e.g. collection rh-mariadb100:
sclo6-el6-rh-mariadb100-build
sclo7-el7-rh-mariadb100-build
sclo6-el6-rhscl-future-rh-mariadb100-build
sclo7-el7-rhscl-future-rh-mariadb100-build
(We need to keep the disttag (el6, el7) in the name as agreed from the beginning for all SIGs)

build targets:
sclo6-el6-rh-mariadb100
sclo6-el6-rh-mariadb100-rhscl-future
sclo7-el7-rh-mariadb100
sclo7-el7-rh-mariadb100-rhscl-future

git branches under sclo/ project:
sclo6-rh-mariadb100
sclo7-rh-mariadb100

git branches under rpms/ project:
sclo6-rh-mariadb100
sclo7-rh-mariadb100

Again, will be glad for any feedback for this..

Honza


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