Ultimately, its about choice. Both methods have some merit.
Currently the time-to-patch (ttp 2-3 days?) is less than the mean-time-between-breakage (mtbb ~14 days). This gives us the luxury of fixing MinGW as we find new holes in it.
If these two time-scales become comparable, then we're in a realm where things are breaking as fast as we can patch them and we would be constantly battling to get a version of MinGW that can produce a winetest.exe.
My *guess* is that on average, the mtbb will decrease, whilst ttp remains constant. That's what it feels like. However, we can wait and see what happens :^)
On Wednesday 16 February 2005 12:35, Filip Navara wrote:
BTW, are there any (other) unofficial Wine patches for the MinGW W32API package?
Yes.
Both Hans Leidekker and myself have a suite of patches; mine are unashamedly taken from Hans (many thanks!) and I don't think there is any difference between our patch-set.
On Wednesday 16 February 2005 22:25, Francois Gouget wrote:
So winetest surely cannot remain broken for a long time.
No, in fact its now working again, now. Just doing an end-to-end test right now.
Finally it's just not the Wine way.
OK, fair point. But, there's two aspects: testing the MinGW code and the winetest.exe compilation service. Whilst ttp < mtbb - \delta, the service works and we can do it the Wine way (the \delta is so people retain their sanity ;)
On Wednesday 16 February 2005 18:39, Alexandre Julliard wrote:
Actually no, fixing MinGW is a very desirable side-effect of cross-compiling our tests. If we find bugs in MinGW they should be fixed, not worked around.
OK, sure.
I think it might be worth trying to push some of these patches up-stream again. That way, we are actually fixing MinGW.
Paul. (as usual, just my 2c worth)