On Fri, May 28, 2010 at 04:22:21PM -0400, David Malcolm wrote: > On Thu, 2010-05-27 at 20:39 -0400, Toshio Kuratomi wrote: > > On Thu, May 27, 2010 at 07:32:23PM -0400, David Malcolm wrote: > > > I've added a list of Python-related features to our wiki page here: > > > https://fedoraproject.org/wiki/SIGs/Python#Python_Features > > > > > > Is anyone else working on Python-related Fedora features? > > > > > You are! > > > > pypy and pynie are good stories for Fedora 14. Although what would make > > this even better is figuring out how to package modules for both of these. > > (following up on this and on an IRC chat on #fedora-python): > > I've speculatively created this feature for PyPy in Fedora: > https://fedoraproject.org/wiki/Features/PyPyStack > > It's not clear to me yet how far to push this: > 1) just the core interpreter, or > 2) sharing pure-Python add-on modules with the system Python (but with > split bytecode files), or > 3) a full, independent Python stack, but with just pure-Python add-on > modules, or > 4) a full, independent Python stack, with both pure-Python and > machine-code extension modules > > Doing e.g. (4) would probably involve a lot of work, though I think we'd > be first to have done it, which would be good in of itself. > > Speaking for myself, I don't yet know if I myself want to sign up for > that. There are particular Python workloads I want to optimize (yum is > one of them), and I don't yet know if PyPy is the best solution for what > I need. (I need to write some systemtap scripts to instrument things). > Yeah -- once we get pypy reviewed, I'll see if I have time to take a look at what we would need in Guidelines to get to the functionality in #4 (and whether we must have independent stacks or can do it with combined package sets).
> > > As for Pynie, I've packaged a prerelease state of upstream SVN, and Tim > Lauridsen reviewed it (bug 593069), but it's at an early stage of > development, and upstream have requested that we not ship it until they > ship tarballs (so I've closed that review out as DEFERRED for now). > Might be interesting to see if upstream would be okay with us building it for rawhide but blocking it from going into any release. We'd have to be proactive about telling releng to block it when we branch for F15, etc, though, if they don't make a release within six months. > > > I've been working on coding kitchen (will package once I get the licensing > > worked out) which may or may not make a good story.... It's a library of > > little code that everyone decided they need to write. So it's little and > > eclectic by nature (not earthshattering) but at the same time we're writing > > it and it would be useful... I'll propose it as a feature if someone prods > > me otherwise I'll consider it just another package. > > > > https://fedorahosted.org/releases/k/i/kitchen/docs > > Is $FOO a feature? There's a checklist at the bottom of this page: > https://fedoraproject.org/wiki/Features/Policy/Definitions > > "kitchen" looks useful, but I'm not convinced that it matches any of the > criteria there. (Don't let me stop you though!) > Yeah -- So I don't really want it to be a feature since it's small and the feature process makes things into a bigger deal than they often are. On the other hand it does fall under: #3 as we're doing work, #3 and #5 if we're trying for a reputation as a distribution for developing python apps, and #4 and #2 if we decide to port yum, createrepo, func, certmaster, python-fedora, etc to them. Hmm... And if we port yum, that means this is going to be a critpath package... /me gets out of a tangent. > > > > * upgrading python3 from 3.1 to 3.2 [3]. This is more uncertain, as > > > the upstream schedule doesn't line up so well with ours. We could > > > potentially package an alpha release I guess. python3 isn't on the > > > critical path, and the number of packages needing a rebuild is _much_ > > > smaller than for Python 2, but I'd want to talk to upstream about it. > > > By comparison, Ubuntu's next release has a slightly later feature freeze > > > than ours, and is planning to ship a beta of 3.2 ([4] and [5]). > > > > > To decide this, we really want to have an idea of features vs risks and how > > long between our release and the upstream 3.2-final release. > > > > * I have a vague remembrance that a lot of good things were added to 3.2 but > > the upstream whatsnew page doesn't yet list things that jog my memory. > > * We probably don't want to ship 3.2alpha1 if final doesn't come out for six > > more months but shipping a late alpha when final is scheduled for two > > months later could be a good tradeoff. > > Lining up the schedules: > DATE PYTHON 3 UPSTREAM FEDORA > 2010-05-25 Fedora 13 Release > 2010-05-28 >Present day > 2010-06-26 Python 3.2 alpha 1 > 2010-07-13 F14 Feature Submission Deadline > 2010-07-24 Python 3.2 alpha 2 > 2010-07-27 F14 Feature Freeze > 2010-07-27 Branch Fedora 14 from Rawhide > 2010-08-03 F14 Software String Freeze > 2010-08-03 F14 Alpha Change Deadline > 2010-08-17 F14 Alpha Release > 2010-08-21 Python 3.2 alpha 3 > 2010-08-31 F14 Software Translation Deadline > 2010-09-07 F14 Beta Change Deadline > 2010-09-18 Python 3.2 beta 1; > 2010-09-18 Upstream feature freeze > 2010-09-21 F14 Beta Release > 2010-10-12 F14 Final Freeze > 2010-10-14 F14 Compose Release Candidate > 2010-10-16 Python 3.2 beta 2 > 2010-10-26 F14 Fedora 14 Final Release > 2010-11-13 Python 3.2 candidate 1 > 2010-11-27 Python 3.2 candidate 2 > 2010-12-11 Python 3.2 final > > Assuming that they turn out to be be true to the day (often a dangerous > assumption!), then at F14 feature freeze on 2010-07-27, upstream would > be at 3.2 alpha 2 (or maybe still alpha 1). Upstream feature freeze is > only 3 days before F14 beta release. > For F13 final, assuming they don't slip by more than a month, we'd likely ship Python3.2-beta1. That seems pretty good. If we were shipping an alpha, it would probably mean we want to ship a snapshot taken after alpha3 somewhere around beta release. The nice thing about that would be that we can ship 3.2 final in F14 when it comes out. The second nice thing is that we should be able to channel more bug reports into upstream around python-3.2. The not nice thing is that we'd also have to work harder on integrating bugfixes. > This also assumes that python3 is not on the critical path, and that > none of the dual-build python2/python3 src.rpms that might in worst-case > need a python3 rebuild have python2 subpackages that _are_ on the > critical path (if that makes sense). > I'm not so worried about rebuilds with python2 subpackages. Where we have to modify source code for python3 and python2 I do get a bit worried. I'm almost regretting that we decided to go with Guidelines that encourage packaging python2 and python3 from a single srpm :-( > I think my chief concerns are > (i) the possibility of ABI breaks during the 3.2 development cycle, > affecting either the .pyc/.pyo format, or the ABI of .so extension > modules. <nod>. So if upstream is good about these things during beta and we're probably going to hit the beta release before final freeze, this seems okay. > (ii) the possibility of irritating upstream by shipping an alpha > We'd need to talk to them... some upstreams welcome distributions shipping latest versions even if they are alphas. And if we hit the beta, it's even better. But... upstreams usually like this when they know we're committing to bringing in bugfixes and releasing frequent updates.... If python3 isn't critpath (I doubt that we're ready to port our critical tools to it. We don't even have a list of dependencies fr our major apps yet...) then we have the option of doing this. But I don't know if we want to... it will be more work. > With rawhide branched for F15 on 2010-07-27, we could simply do this in > rawhide for F15. > This is a good point. Essentially we have nearly a year of development for any given release because of the early branching... so in some ways it would have been good to have this in F14 rawhide already. So... if we want to be leaders for F14... we could do it. But I think we might want to hold off due to lack of resources at this time.... I still haven't found a list of the enhancements that 3.2 brings so I don't know what the rewards of moving to python-3.2 are.... > As for Python 2, I think the case for 2.7 for F14 is fairly clear, and > it's just a case of getting ready, then doing it. I plan to help fix > anything that breaks - but I'm going to be on vacation from June 9th > through 20th, and hopefully _not_ on a computer, so we either want to do > it ASAP, or after the 20th. It may be sanest to wait until after I'm > back; upstream plan to release RC2 on the 19th. > I think we should be pushing this out now. Upstream is on the last python-2.7 beta now we should push that out to rawhide/F14. This is because: 1) rawhide is expected to be least stable right after a release. 2) If any programs break because of the python update, this gives us the most time to diagnose and fix it in either python or the apps. Holding off once the beta goes out just reduces this window. -Toshio
pgpT9MTIYOPxG.pgp
Description: PGP signature
_______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
