removed bad and not proven statemets...

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@2911 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files 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.
 <P>The <I>background</I> : there were/are the GCC <B>2.95</B> 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.</P>
+We never ever saw anything that was miscompiled because of the 2.95's faultiness.</P>
 
 <P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
 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 <B>bad</B>. RedHat saw it was bad, but decided to ship it
-anyways (even with his "<I>Enterprise-ready</I>" 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 <B>GCC 3.0</B>)</P>
-
-<P>The <I>result</I> : the first RedHat GCC 2.96's were so flawed, that nothing
-above <I>hello_world.c</I> 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 <B>DRI</B>, <B>avifile</B>, <B>Wine</B> and the <B>Linux kernel</B>
-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.</P>
+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.</P>
 
 <P>The <I>statements</I> : 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
-<B>to fix</B> 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.</P>
 
 <P><I>Present age, present time</I> : 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 <B>RedHat
-will forget about 2.96</B> and turn towards <B>3.0</B>.</P>
+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 <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
+Towards a deep patched 3.0...
+</P>
 
 <P><I>What I don't understand</I> is why are we hated by RedHat users for
 putting warning messages, and stay-away documents in <B>MPlayer</B> .