Hi folks, As mentioned in another thread, I'm finally getting started on bootstrapping a "rolling Python" SCL that follows the latest upstream releases (so it will follow 3.6 until the 3.7.0 release, then switch to following 3.7, etc, etc).
Part of that involves officially signing up for SCLo SIG membership in the build system, so this is a note to say that: 1. I've applied for sclo-sig membership via accounts.centos.org 2. My account name is "ncoghlan" (but using my personal address rather than my RH one) 3. The purpose of the application is to set up a "sclo-python" community SCL that tracks the latest upstream stable release as described above At some point we may want to add a "sclo-python-preview" stream that includes the release candidates issued prior to upstream maintenance releases, and switches to the next maintenance branch once the first beta comes out, but if I/we do do anything like that, it would most likely be driven by the start of the 3.7 beta cycle rather than being something that gets done immediately. I'm starting the repo for this at https://github.com/ncoghlan/sclo-python/ (to be transferred to https://github.com/sclorg-distgit at a later date), and will chat to Tomas Orsava about how best to go about seeding that. Cheers, Nick. P.S. I'm starting to think it may actually make sense to start out with the 3.5 Red Hat SCL as a template, and then do a 3.5 -> 3.6 transition within the sclo-python stream to make it absolutely clear that when we say "rolling release, including major version upgrades" we really do mean "rolling release, including major version upgrades". Otherwise, regardless of what we say in the docs, I can see folks getting upset when the 3.6 -> 3.7 switch comes around and they happened to be relying on a previously deprecated feature that had finally been removed. -- Nick Coghlan Red Hat Platform Engineering, Brisbane _______________________________________________ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg