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:
