collinw at gmail.com
Fri Mar 27 15:38:00 CET 2009
On Fri, Mar 27, 2009 at 5:50 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 2009/3/27 Collin Winter <collinw at gmail.com>:
>> In particular, Windows support is one of those things we'll need to
>> address on our end. LLVM's Windows support may be spotty, or there may
>> be other Windows issues we inadvertently introduce. None of the three
>> of us have Windows machines, nor do we particularly want to acquire
>> them :), and Windows support isn't going to be a big priority. If we
>> find that some of our patches have Windows issues, we will certainly
>> fix those before proposing their inclusion in CPython.
> On the assumption (sorry, I've done little more than read the press
> releases so far) that you're starting from the CPython base and
> incrementally patching things, you currently have strong Windows
> support. It would be a shame if that got gradually chipped away
> through neglect, until it became a big job to reinstate it.
That's correct, we're starting with CPython 2.6.1.
> If the Unladen Swallow team doesn't include any Windows developers,
> you're a bit stuck, I guess, but could you not at least have a Windows
> buildbot which keeps tabs on the current status? Then you might
> encourage interested Windows bystanders to check in occasionally and
> maybe offer fixes.
We're definitely going to set up buildslaves for Windows and other
platforms (currently we're only running Linux buildslaves). We're
trying to solicit 20% time help from Google Windows developers, but
that experience is relatively rare compared to the vast sea of
Linux-focused engineers (though that's true of the open-source
community in general). Also, it may be that some of the components
we're reusing don't support Windows, or perhaps worse, offer degraded
performance on Windows. We believe we can fix these problems as they
come up -- we certainly don't want Windows issues to prevent patches
from going into mainline -- but it's still a risk that Windows issues
may slow down our development or prevent us from doing something fancy
down the road, and I wanted to be up front about that risk.
I've updated our ProjectPlan in hopes of clarifying this. That section
of the docs was copy/pasted off a slide, and was a bit too terse :)
More information about the Python-Dev