[scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13)

Honza Horak hhorak at redhat.com
Mon Jan 18 11:49:14 UTC 2016

On 01/14/2016 07:35 AM, Nick Coghlan wrote:
> On Thu, Jan 14, 2016 at 3:33 AM, Honza Horak <hhorak at redhat.com> wrote:
>> #topic review of how development of new scls is working
>>    rought proposal: building packages -> candidate -> sanity testing ->
>> testing -> [wait till rhscl is released] -> tag released -> sign&release
>>    - usual tagging process: tag -candidate -> [sanity testing] -> tag
>> -testing -> [better testing] -> tag -released -> sign&release
>>    - how it will be done for collections that gonna be released in RHSCL in
>> the future?
>>    - idea: such collections should stay in -testing until they are released
>> in RHSCL -- bad idea? shout now.
> What's the scope of discussion here in terms of "sclo-*" SCLs and "rh-*" SCLs?
> For "sclo-*" SCLs, I'd expect the RHSCL release cycle to be entirely irrelevant.

Yes, they may be theoretically influence in cases the sclo-* SCLs depend 
on some rh-* SCLs -- in that case their release is depended on RHSCL.

> For "rh-*" SCLs, having them remain in -testing until the downstream
> release (so they become generally available to RHEL & CentOS users at
> the same time) seems reasonable.
> So if someone wanted to take an existing rh-* package and turn it into
> an sclo-* package that could be updated independently of the RHSCL
> release cycle, they'd be free to do that.

Yes, in case someone would like to include different set of packages or 
deliver different version, then it effectively become a new SCL, that 
needs to be treated that way.


More information about the SCLorg mailing list