On 07/24/2013 02:21 AM, Rene BRANDT wrote:
I worked 40 years on IBM mainframes and we never had a problem of new release because all parts of old release were included in the new release. Why can't you do the same ?
And they had dedicated QA teams. (Oh, what a difference a QA team makes when developing a complex product!)
I have not personally tested the Windows release, because I don't need it -- which is why I have no idea it works. German says it does, so I'll defend it as if it does.
Rene, it's worth not overlooking the fact that GNUstep is not selling you a single, complete product. It's not even shipping you a product intended to run on "only" 4 setups. Or even on "only" 4 platforms.
GNUstep runs on at least the following platforms: Linux, FreeBSD, Windows. GNUstep runs on at least the following CPUs: i386, x86, arm, mips -- and this is just based on what libobjc2 supports. You can probably get the system up and running using other libraries. Now imagine various FreeBSD versions and Linux versions people use.
You can say "Okay, but that's all when compiling from sources. Power of open source is that people can mix-and-match. But, I want to run the Windows release!"
Based on the setups people had on the recent dev meeting in Cambridge, Windows doesn't seem like a priority platform. I don't think I saw anyone actually running Windows on their machines when we were there.
So this means that the person creating the Windows release (Adam, I think?) does the primary testing. Some cursory testing. There is no QA team that will take the packages and doublecheck.
While it's very important to support Windows as a learning platform (a lot of people could use it to teach themselves Objective-C and decide to explore GNUstep on a more supported platform), it's really unfair to compare a project whose developers volunteer to develop software for UNIX systems that they use, to a company staffed with well-paid engineers releasing commercial software backed by various support contracts.
If someone considered perfect Windows support to be a mission critical investment for their commercial venture, or if someone came a long that considered perfect Windows support critical to their warm-and-fuzzy feeling, sure, one could expect testing on Windows XP, Windows XP 64-bit, (and various "Home" and "Professional" editions), Windows Vista, Windows Vista 64-bit (in all its multi-edition glory), Windows 7, Windows 7 64-bit, Windows 8, Windows 8 64-bit, as well as numerous server releases including r2 variants.
(And yes, it is necessary to ensure the system works for everyone as you, Rene, expect it to. At a game company I worked for, our games written in PythonOgre wrote player profiles to disk as XML files with a different extension. Under Windows 7, this started failing about 30-40% of time. As in, 'permission denied'. A str_replace() of </> with {/} before saving, then reversing this before parsing XML when loading, got the player profiles to work.
Does Windows 7 parse data being written to disk before closing the file? Is it Python's fault perhaps, where it parses the XML and breaks for some reason on Windows 7? I have no idea, but it sure seemed like it was Windows 7's fault. It's such a totally unexpected bizarre thing to happen that I did not believe it when colleagues complained. Until I witnessed it myself while working on another game!)