[scl.org] Python "latest" SCLo

[Honza Horak]

On 07/12/2017 08:22 AM, Nick Coghlan wrote:
> 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.

Ok, that makes sense to me, I'll ask for the tags/targets for 
"sclo-python" SCL if there are no objections about naming later this week.

Honza

> 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/
>