On Thu, 29 Jan 2015 09:39:28 -0500 (EST) Bohuslav Kabrda <bkabrda@xxxxxxxxxx> wrote: > Not sure about it being the default, but we've been testing it in > DevAssistant for dependency installation on Python 3 and never > encountered any problems. I was also contacted by dnf maintainer with > a question on how to switch "dnf" to use > "python3-dnf" (package-wise), so I guess that's what will be done for > F22 (but that's just my guess, dnf maintainer would have to comment > here). See the thing there that makes my teeth itch is: dnf has been massively great about having a long on-ramp. It appeared, it didn't replace yum, it let people try it out and report bugs, there was a long time of testing. Thats all great. But now, we switch it to dnf-3 and... that has not had years of running in rawhide and other releases, it has not had people testing it and reporting bugs. While the code overlap could be pretty large, I am willing to bet a shiny us dollar that there are some python 3 specific bugs lurking in it. So, we turn on this not very tested path and immediately try and use it as default in anaconda and a new release. What happened to our nice long ramp? Or any ramp? > > Even still, that hinges on DNF being the default package manager in > > F22. There are some concerns that it won't make it due to rel-eng > > tooling used to compose the images, etc. If that's the case, yum > > will still be required. > > Required, yes, but we'll still have tons of packages built with > Python 2. I never said that porting rel-eng tooling is the goal for > F22. Might be good to note that on the change page: We will not be replacing python2 entirely, it and packages that depend on it will still be available for now. > So if more minimal is minimal buildroot, then we can achieve that, > since it only has python-libs because of gdb and gdb can be rebuilt > with Python 3 (upstream source is compatible). If that means minimal > cloud image, then we can do it (we're waiting for the cloud-init > folks to accept the py3 patches, which should happen any time now). > If that means content from fedora-live-base.ks, then we can do pretty > much everything, except of samba (I think) - and Petr Viktorin is > doing some talking to people to get rid of samba from this config, > because it seems to be unnecessary there. ok. So, perhaps we should have a change around this for f22, but it should be: Python 3 migration improvements or something, not 'default' ? > Considering all the information mentioned above and assuming Anaconda > makes it, I'd say it should be perfectly possible to declare Python 3 > the default. As for the packages that are not in the minimal > installs, I can always open bugs for them before beta and only those > maintainers who believe it to be safe can switch. Yeah, so if anaconda switches we get: * anaconda switches to dnf (this is already done in rawhide after last branch point, so I think it's quite safe/doable). * anconda switches to dnf-3 (if we land that change. It's gotten 0 testing that I know of). * anconda switches to python3 (it's almost ready, but no telling what issues we will hit, it's not even landed yet). Should we toss in a UI redesign so we can have Fedora 18 again? (sorry, that was rude of me) Wouldn't it be safer to defer dnf-3 and anaconda-py3 for next cycle, but make those changes in rawhide after the branch point? Then they would actually get months of shake out... kevin
Attachment:
pgpQwO3HXMc42.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
