On Thu, Jul 25, 2013 at 10:03 AM, Pascal J. Bourguignon <
[email protected]> wrote:
> 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 ?
>>
>
> The difference is that IBM got paid some serious money by millions of
> companies to get those nice bugfree releases.
>
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!)
--
Ivan Vučica
[email protected]
_______________________________________________
apps-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/apps-gnustep
