RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-26 00:42:57 +00:00
Code Issues Releases Wiki Activity

removed bad and not proven statemets...

Browse Source 
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@2911 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
arpi 2001-11-14 22:45:53 +00:00
parent 113336b4c3
commit 6f1f7cb504
1 changed files with 10 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
DOCS/users_against_developers.html
View File

@ -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> .