From 6f1f7cb504141b9e16ca8c6d8b9715b08880eaee Mon Sep 17 00:00:00 2001 From: arpi Date: Wed, 14 Nov 2001 22:45:53 +0000 Subject: [PATCH] removed bad and not proven statemets... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@2911 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/users_against_developers.html | 37 ++++++++---------------------- 1 file changed, 10 insertions(+), 27 deletions(-) diff --git a/DOCS/users_against_developers.html b/DOCS/users_against_developers.html index da1542c7e5..330f98e935 100644 --- a/DOCS/users_against_developers.html +++ b/DOCS/users_against_developers.html @@ -22,45 +22,28 @@ lots of other features.

The background : there were/are the GCC 2.95 series. The best of them was 2.95.3 . Please note the style of the version numbering. This is how the GCC team numbers their compilers. The 2.95 series are good. -Noone ever saw anything that was miscompiled because of the 2.95's faultiness.

+We never ever saw anything that was miscompiled because of the 2.95's faultiness.

The action : RedHat started to include a GCC version of 2.96 with their distributions. Note the version numbering. This should be the GCC -team's versioning. They patched GCC 2.95.3 . They patched it very deep. -They patched it bad. RedHat saw it was bad, but decided to ship it -anyways (even with his "Enterprise-ready" distributions). After all, more -users try it, the more bugreports they get, thus bugfixing and development -goes faster. Development? GCC 2.95 was good enough, where did they want to -develop more? Develop GCC in parallel with the GCC team ? (the GCC team was -meanwhile testing their new GCC 3.0)

- -

The result : the first RedHat GCC 2.96's were so flawed, that nothing -above hello_world.c compiled. RedHat immediately began making -Service Packs - ups, so they immediately began patching the bugs. They -could have backed out to 2.95 if they wanted. Meanwhile major Linux programs' -like DRI, avifile, Wine and the Linux kernel -developers began wondering why do they receive these new interesting -bugreports. They obviously didn't consider it a good thing, they'd have -better things to do.

+team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0) +They patched it very deep, and used this version in the distrib, because 3.0 +wasn't out at time.

The statements : most developers around the world begun having bad feelings about RedHat's GCC 2.96 , and told their RedHat users to compile with other compiler than 2.96 . RedHat users' disappointment slowly -went into anger. Some guy called Bero even put up a page that describes -that GCC 2.96 is not incompatible, but 2.95 was incompatible ! If we -assume this is the case, we should greet RedHat for upgrading our GCC, and -flame all who opposes. But I wonder : why didn't they help the GCC team -to fix their "incompatibilities", why did they instead fork, and -did it on their own? Why couldn't they wait for GCC 3.0 ? What was all good +went into anger. What was all good for, apart from giving headaches to developers, putting oil on anti-RedHat flame, confusing users? The answer, I do not know.

Present age, present time : RedHat says that GCC 2.96-85 and above is fixed, and works properly. Note the versioning. They should have started -with something like this. What about GCC 2.95.3-85 ? It doesn't matter now. -Whether they still use kgcc for kernels, I have no information. I don't search, -but I still see bugs with 2.96 . It doesn't matter now, hopefully now RedHat -will forget about 2.96 and turn towards 3.0.

+with something like this. What about GCC 2.96.85 ? It doesn't matter now. +I don't search, but I still see bugs with 2.96 . It doesn't matter now, +hopefully now RedHat will forget about 2.96 and turn towards 3.0. +Towards a deep patched 3.0... +

What I don't understand is why are we hated by RedHat users for putting warning messages, and stay-away documents in MPlayer .