On 07/12/2017 08:22 AM, Nick Coghlan wrote:
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.
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/de...@lists.fedoraproject.org/thread/AKSJ67CS5G7WBQQKO6OCIISC3ARSUG7L/
_______________________________________________
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
