[Mingw-cross-env-list] Mingw in a production environment

[Daniel Stonier]

At the risk of raising some previously discussed issues, I'd like to bring up the point concerning the manner in which mxe retrieves sources again and its associated problem - broken urls.  This causes us quite some difficulty when considering the use of mxe in a production environment.

1) Downtime

It's very important for us or our users to be able to download the current version of mxe and have it build correctly. If it's down (broken url's break the compile) 1% of the time, that is 1 out of 100 users that's going to be raising questions/issues. I suspect the figure is much higher than 1% (the latest freetds broken url took 8+days which is already 2.5% of every year). Having almost 0% downtime should be a very important goal for the current stable release of mxe.

2) Previous Releases

We've got software tagged and continuously being used - some of this is two years old and that software just receives the odd bugfix. The problem with mingw is we can't tag it anywhere. We're forced to use the latest mxe because that is the only one with guaranteed url's which would be fine, but the software versions inside mxe are constantly moving. An example:

Some two year old software was using mingw/mxe and at the time boost was version 1.46. To bugfix something now and recompile with the latest mxe means we're forced to use boost 1.50 and our old software will no longer compile due to various changes in boost. Sure, we could fix the compile problems and upgrade our tagged software to use boost 1.50, but to maintain quality control, we'd have to do an entirely new round of stability testing (since we're doing robotics, this is often not practical or feasible). 

The problem, as always, is those broken url's. A quick easy solution to reduce downtime of the currently supported release:

• Have more people on the mxe project whose role need only be to process/test pull requests for broken urls. 
• Do a continuous integration build nightly to automatically verify  things. At it's simplest, this could just be a download check for broken url's. At its best, this could farm out full build jobs to different platforms to automatically very the build is working/not working. This way problems can be detected and solved without leaving that job to users.

I can probably get my company to set up jenkins on their public server without too much hassle. I don't know if they'd approve doing full builds on the server, but it could at least do broken url's and build jobs for slaves.

To fix 2) I can't see any other way than to take control of the problem and maintain a server and mirrors where we collect sources. Ultimately any linux platform has to do this for their own packages and I don't consider mxe being that much different from a full distro as it grows. I suspect the best plan would be to contact universities who host various open source repositories and see if they would be willing to host mirrors for mxe as well.

Regards,

Daniel Stonier