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