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

[Honza Horak]

On 03/11/2015 05:05 PM, Honza Horak 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..

Still no feedback?

Small update in the future RHSCL workflow:
https://www.redhat.com/archives/sclorg/2015-March/msg00030.html

Honza

> 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
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel