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? Honza