Hello, I will not be able to attend, but Brian Stinson has offered to chair the meeting. An agenda will be sent out on Thursday, but I think the main focus will be on what is needed to get python3x into EPEL and in that discussion what things we are going to want out of short-lifed packages in a long term repo. [EG python34 will be EOL sometime after python35 comes out.. the same with 35 when 36 comes out. Does saying that it would be great to have dual stack support actually something we can deliver or should we go with you can't have python34 and python35 installed at the same time.]
----- Original Message -----
Hello, I will not be able to attend, but Brian Stinson has offered to chair the meeting. An agenda will be sent out on Thursday, but I think the main focus will be on what is needed to get python3x into EPEL and in that discussion what things we are going to want out of short-lifed packages in a long term repo. [EG python34 will be EOL sometime after python35 comes out.. the same with 35 when 36 comes out. Does saying that it would be great to have dual stack support actually something we can deliver or should we go with you can't have python34 and python35 installed at the same time.]
I believe that having both stacks coexist for some limited amount of time is necessary here. Without that, we would be hitting periods with really broken/incomplete python3 stack and I think we want to avoid that. I already created a copr repo for this [1] where I'll start landing first builds today for everyone to test - doing parallel installable python3X stacks is actually pretty easy and I pretty much have everything working locally right now, so I really recommend to go with parallel installable stacks (while I agree that the period when both coexist should be kept to minimum).
-- Stephen J Smoogen.
epel-devel@lists.fedoraproject.org