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

[Honza Horak]

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