----- Original Message -----
> Hi all,
> I know I've been promising this for quite some time to several people, so I
> finally managed to put together a proposal for packaging Python 3 in EPEL 7
> (it'd also scale to EPEL 6 for that matter).
> I've created a wiki page  with the proposal and I'd like to hear comments
> and thoughts on it. There are some TODOs and variants in few places - I'd
> like to hear your opinions on these, or perhaps suggestions on better
> I'll create new documents with the updated proposal at some points during the
> discussion, so that people can easily see where the proposal is going
> without having to compare wiki revisions.
> Is there any other list/interested parties that should be put in CC of this
> mail? If so, please feel free to respond and do that yourself.
> Slavek Kabrda
>  https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
- Nick Coghlan posted an interesting proposal to the discussion section in my proposal (my reaction is in the blue frame) . I'd appreciate more comments on this.
- From the feedback gathered on this list:
- We should have /usr/bin/python3 pointing to a python3X build. The question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important).
- As for dist-git possibilities, Orion would prefer to use current dist-git repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish.
- Stephen Smoogen mentioned that the transitional period during which python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like "3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good thing here, I think)
- As I noted in one of my emails, we don't have to worry about conflicts with RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus won't conflict with python3X stacks.
Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)).
I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way.
epel-devel mailing list