On Thu, Jul 7, 2016 at 5:13 PM, Honza Horak <[email protected]> wrote: > On 07/04/2016 03:11 PM, Nick Coghlan wrote: >> Is there an ETA for when the RHSCL collections will get a proper >> upstream that accepts patches, rather than just bug reports? (I >> thought establishing that was part of the purpose of the CentOS SIG) > > It is possible already now. The important thing is that such patches may get > into a collection that is *different* than the collections shipped by Red > Hat, but we won't block anybody to introduce such a new collection with for > example more frequent updates. > > What it means in practice -- say you want python 3.5 collection that is > following upstream releases more closely than rh-python35 and provides > patches that are not included in rh-python35 SCL -- then this SCL will need > to be called differently, say sclo-python35 or nick-python35 or anything > else following the pattern owner-nameVersion. You're free to introduce such > SCL but we cannot expect SCLo SIG will do it for all collections, since it > requires too much resources we simply don't have currently.
Ah, so if there was (say) an "sclo-python35" SCL, then changes made there *might* be taken into account when future versions of rh-python35 were defined? (similar to the way not all Fedora changes will make their way into RHEL). Is there a short summary of the steps and obligations involved in proposing a new sclo-* collection? There are some notes on https://wiki.centos.org/SpecialInterestGroup/SCLo but they're not especially clear on the steps for defining a new collection, and then maintaining it over time. Regards, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane _______________________________________________ SCLorg mailing list [email protected] https://www.redhat.com/mailman/listinfo/sclorg
