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

[Campbell, Stuart I.]

On 3/11/15, 12:05 PM, "Honza Horak" <hhorak at redhat.com> wrote:

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

I asked around a few users at my work place (large national lab) and they didn’t seem to be confused at all about the ‘rhscl’ naming.  People pretty much guessed that these were collections that were part of rhscl.  Although the ‘sclo’ naming did seem to confuse pretty much everyone - but that’s a different issue.

Cheers
Stu