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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel