[scl.org] Python "latest" SCLo

[Nick Coghlan]

On Tue, Jul 11, 2017 at 11:39 PM, Honza Horak <hhorak at 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/devel@lists.fedoraproject.org/thread/AKSJ67CS5G7WBQQKO6OCIISC3ARSUG7L/

-- 
Nick Coghlan
Red Hat Platform Engineering, Brisbane