(original) (raw)
On Tue, Jul 5, 2011 at 14:41, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin@gmail.com> wrote:On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@gmail.com> wrote:�Cygwin is not really a supported platform.
...\[Ultimately somebody with an
interest in cygwin will need to get active in python development. I've
been meaning to do this but life gets in the way.]
I was bitten by the lack of Cygwin support in 3.2 as well.
IMO,� python-dev needs continuous integration on a build farm that includes representative platforms.� Most of the machines in the farm could be virtualboxes.
I don't think the problem is so much that the right people haven't gotten involved, as that the currently-involved people don't know when they're breaking something for someone else due to the lack of continuous integration.We've had that for some time now:�http://www.python.org/dev/buildbot/
Good to know.� Apologies for my incorrect assumption.� Where do the e-mail notifications of build and/or test failures go?
There might be an RSS feed or something, but I don't think there's any email notification. #python-dev on IRC receives live failure info. Other than that, you'd just have to look at one of the views of the fleet to see which build slaves are failing.
�
Shouldn't Cygwin be represented here?� I don't see it in the list of builds.
Probably, but it isn't represented because no one contributed a build slave for it. I know some of the other Windows build slave operators use Cygwin to some degree, but I'm not sure if anyone has looked into actually setting up a build slave for it.
Some shops have a policy that nothing gets merged into trunk unless it's passing critical automated tests...� Would that work here?
We don't make much use of branching, but that would work if we did. If no one is actively contributing work on the Cygwin build then I don't see us holding up work in order to figure out any Cygwin-specific issues.
There are several issues on the bug tracker about cygwin build issues, but to my knowledge, none of them have included successful patches.
I think you'll find that most people using Cygwin would rather be working on some other OS, but are forced to use Windows for policy reasons.� It's remains a rather significant need in many cases.
I don't disagree with that, but if there's no one contributing Cygwin patches then it will probably just die off and we'll have situations like the current one where it doesn't build. A great majority of the contributing developers are on UNIX-based systems with no access to Windows. A small handful, myself included, are Windows users, but I don't think any of us use Cygwin (I don't).
Native Windows builds do appear to be represented.� Is there any reason not to set up a buildbot for Cygwin on the same (virtual?) hardware?
Besides the time and effort needed to set it up and occasionally look over it, no. We'd have to have a successfully compiling Cygwin build before we think about adding a build slave for it.
I wouldn't be opposed to hosting this myself, but I need to steal some time and get my Windows 2008 build slave back to some form of a functional system - it has been up and down for a few months now. If someone else is interested, go ahead.