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