Hi, I'm a relative outsider to core development (I'm just a Plone release manager), but'll allow myself a couple of questions. Feel free to ignore them, if you think they are not relevant at this point :-) I'd note that I'm generally enthusiastic and supportive of the proposal :) As a data point, I can add that all tests of Zope 2.12 / Plone 4.0 and their dependency set run fine under Unladen Swallow.
On Wed, Jan 20, 2010 at 11:27 PM, Collin Winter <collinwin...@google.com> wrote: > We have chosen to reuse a set of existing compiler libraries called LLVM > [#llvm]_ for code generation and code optimization. Would it be prudent to ask for more information about the llvm project? Especially in terms of its non-code related aspects. I can try to hunt down this information myself, but as a complete outsider to the llvm project this takes much longer, compared to someone who has interacted with the project as closely as you have. Questions like: - Who holds the copyright, is there a foundation or is there a risk of the project getting into trouble because of copyright issues? - What licence is the code and the tools under and what affect does that have on the code generated by the JIT compiler? - What's the bus factor of the project? Is it in practice dependent on a single BDFL or a single company like Apple? - What's the status of the documentation or web presence? Does the project consist only of developers or has it been able to attract people from other backgrounds? On the code related side you described general enthusiasm and support of the llvm community, but noted that some aspect of it aren't as mature as others. You also noted that given Python's good test coverage you have been able to find problems in llvm itself. This raises some questions to me: - Does the llvm project employ automated test driven development, are there functioning nightly test runs? - What do they do to ensure a good quality of their software, how many critical regressions have their been in final releases? - Is there a clearly distinguished core and stable part of the project that is separate from more experimental ideas? - What's the status of their known bugs? Do "important" issues get resolved in a reasonable time? - Did they have security problems related to their codebase, have those been handled in a professional manner? There's probably more of these questions you tend to ask yourself somewhat implicitly when trying to assess how mature and stable a given open-source project is. My feeling is that llvm is still a slightly new and up and coming project and it would be good to get a better idea about how mature they are. > Platform Support > ================ > > Unladen Swallow is inherently limited by the platform support provided by > LLVM, > especially LLVM's JIT compilation system [#llvm-hardware]_. LLVM's JIT has the > best support on x86 and x86-64 systems, and these are the platforms where > Unladen Swallow has received the most testing. We are confident in > LLVM/Unladen > Swallow's support for x86 and x86-64 hardware. PPC and ARM support exists, but > is not widely used and may be buggy. How does the platform support work with new versions of operating systems? If for example a Windows 8 is released, is it likely that llvm will need to be adjusted to support such a new version? What kind of effect does this have on how a Python release can add support for such a new version? Is there evidence from past releases that give an indication on the time if costs the llvm team to support a new version? Do they only add support for this to their latest release or are such changes backported to older releases? The Windows support doesn't seem to be a specific focus of the project. Are there core developers of llvm that run and support Windows or is this left to outside contributors? Is the feature set the same across different operating systems, or are there areas in which they differ in a significant manner? > Managing LLVM Releases, C++ API Changes > --------------------------------------- > > LLVM is released regularly every six months. This means that LLVM may be > released two or three times during the course of development of a CPython 3.x > release. Each LLVM release brings newer and more powerful optimizations, > improved platform support and more sophisticated code generation. How does the support and maintenance policy of llvm releases look like? If a Python version is pegged to a specific llvm release, it needs to be able to rely on critical bug fixes and security fixes to be made for that release for a rather prolonged time. How does this match the llvm policies given their frequent time based releases? Sorry if those questions aren't appropriate. It's what comes to my mind when thinking about a new and quite heavy dependency :-) Hanno _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
