On Tue, Jul 11, 2017 at 11:39 PM, Honza Horak <hho...@redhat.com> wrote: > On 07/11/2017 10:44 AM, Nick Coghlan wrote: >> 1. Create a new sclo-python metapackage, using >> https://github.com/sclorg-distgit/rh-python35/tree/master as a >> starting point >> 2. For now, just create a `sig-sclo7-sclo-python` branch (we can look >> at an sclo6 branch once 7 is working) >> 3. Edit https://github.com/ncoghlan/sclo-python/tree/sig-sclo7-sclo-python >> for the rh-python35 -> sclo-python name change >> 4. Start doing some test builds in COPR as per >> https://www.softwarecollections.org/en/docs/ > > This guide is actually not complete, as I've just realized -- copr is only > one way to build SCLs for www.softwarecollections.org, but we can include > SCLs from CBS (cbs.centos.org, build by SCLo SIG) as well. We should fix > this part of documentation, thanks for pointing to it..
I wasn't planning to publish the COPR builds anywhere other than COPR, they'd just be a place for me to tinker with things before pushing them into CBS as real builds. >> In parallel with that: >> >> 4. Submit a buildsys request for an sclo-python tag that's similar to >> the existing rh-python35 one (akin to >> https://bugs.centos.org/view.php?id=9661 ) > > I can help with requesting CBS stuff, I think we can request both and build > el7 first.. existance of the tag el6 does not mean we need to ever release > it.. if we don't want to from some reason.. I'm happy to publish both, I just figured it made sense to focus on EL7 first, since I've never been through this process before :) So the two pieces here would be: - my sig-sclo membership request is currently still pending in https://accounts.centos.org - we'll need to file a tag request once we agree on the name > The only thing we need to make clear is the naming -- sclo-python3 or > sclo-python? From my PoV sclo-python3 better describes what is inside.. but > maybe there are other opinions.. If there's ever a Python 4.0, I'd update the rolling SCL to track it rather than sticking with the last 3.x release, so I think "sclo-python" conveys that intent more clearly. I'm also assuming that as long as there's customer demand for them, RH will continue to provide the version specific "rh-pythonXY" SCLs (or something functionally equivalent), so there isn't going to be any great need to restrict the rolling SCL updates - folks will be able to move onto sclo-python if they want to get ahead of the rh-pythonXY streams for some reason, and then potentially drop back to the Red Hat ones if they want to stick with an older release for a while even after a new one becomes available. In Fedora Modularity [1,2] terms, I'm essentially seeing sclo-python as corresponding to a "latest" stream label, while the various rh-pythonXY SCLs would correspond to "X.Y" stream labels. Cheers, Nick. [1] https://docs.pagure.org/modularity/ [2] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/AKSJ67CS5G7WBQQKO6OCIISC3ARSUG7L/ -- Nick Coghlan Red Hat Platform Engineering, Brisbane _______________________________________________ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
