Mercurial > mplayer.hg

comparison DOCS/users_against_developers.html @ 2910:56428bdf583e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
removed bad and not proven statemets...
author arpi
date Wed, 14 Nov 2001 22:45:53 +0000
parents a9a63f7e9ddc
children 40254e0cba96
comparison
equal deleted inserted replaced
2909:8551ccd5fab7 2910:56428bdf583e
20 lots of other features. 20 lots of other features.
21 21
22 <P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The 22 <P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The
23 best of them was 2.95.3 . Please note the style of the version numbering. 23 best of them was 2.95.3 . Please note the style of the version numbering.
24 This is how the GCC team numbers their compilers. The 2.95 series are good. 24 This is how the GCC team numbers their compilers. The 2.95 series are good.
25 Noone ever saw anything that was miscompiled because of the 2.95's faultiness.</P> 25 We never ever saw anything that was miscompiled because of the 2.95's faultiness.</P>
26 26
27 <P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B> 27 <P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
28 with their distributions. Note the version numbering. This should be the GCC 28 with their distributions. Note the version numbering. This should be the GCC
29 team's versioning. They patched GCC 2.95.3 . They patched it very deep. 29 team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0)
30 They patched it <B>bad</B>. RedHat saw it was bad, but decided to ship it 30 They patched it very deep, and used this version in the distrib, because 3.0
31 anyways (even with his "<I>Enterprise-ready</I>" distributions). After all, more 31 wasn't out at time.</P>
32 users try it, the more bugreports they get, thus bugfixing and development
33 goes faster. Development? GCC 2.95 was good enough, where did they want to
34 develop more? Develop GCC in parallel with the GCC team ? (the GCC team was
35 meanwhile testing their new <B>GCC 3.0</B>)</P>
36
37 <P>The <I>result</I> : the first RedHat GCC 2.96's were so flawed, that nothing
38 above <I>hello_world.c</I> compiled. RedHat immediately began making
39 Service Packs - ups, so they immediately began patching the bugs. They
40 could have backed out to 2.95 if they wanted. Meanwhile major Linux programs'
41 like <B>DRI</B>, <B>avifile</B>, <B>Wine</B> and the <B>Linux kernel</B>
42 developers began wondering why do they receive these new interesting
43 bugreports. They obviously didn't consider it a good thing, they'd have
44 better things to do.</P>
45 32
46 <P>The <I>statements</I> : most developers around the world begun having 33 <P>The <I>statements</I> : most developers around the world begun having
47 bad feelings about RedHat's GCC 2.96 , and told their RedHat users to 34 bad feelings about RedHat's GCC 2.96 , and told their RedHat users to
48 compile with other compiler than 2.96 . RedHat users' disappointment slowly 35 compile with other compiler than 2.96 . RedHat users' disappointment slowly
49 went into anger. Some guy called Bero even put up a page that describes 36 went into anger. What was all good
50 that GCC 2.96 is not incompatible, but 2.95 was incompatible ! If we
51 assume this is the case, we should greet RedHat for upgrading our GCC, and
52 flame all who opposes. But I wonder : why didn't they help the GCC team
53 <B>to fix</B> their "incompatibilities", why did they instead fork, and
54 did it on their own? Why couldn't they wait for GCC 3.0 ? What was all good
55 for, apart from giving headaches to developers, putting oil on anti-RedHat 37 for, apart from giving headaches to developers, putting oil on anti-RedHat
56 flame, confusing users? The answer, I do not know.</P> 38 flame, confusing users? The answer, I do not know.</P>
57 39
58 <P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above 40 <P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above
59 is fixed, and works properly. Note the versioning. They should have started 41 is fixed, and works properly. Note the versioning. They should have started
60 with something like this. What about GCC 2.95.3-85 ? It doesn't matter now. 42 with something like this. What about GCC 2.96.85 ? It doesn't matter now.
61 Whether they still use kgcc for kernels, I have no information. I don't search, 43 I don't search, but I still see bugs with 2.96 . It doesn't matter now,
62 but I still see bugs with 2.96 . It doesn't matter now, hopefully now <B>RedHat 44 hopefully now <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
63 will forget about 2.96</B> and turn towards <B>3.0</B>.</P> 45 Towards a deep patched 3.0...
46 </P>
64 47
65 <P><I>What I don't understand</I> is why are we hated by RedHat users for 48 <P><I>What I don't understand</I> is why are we hated by RedHat users for
66 putting warning messages, and stay-away documents in <B>MPlayer</B> . 49 putting warning messages, and stay-away documents in <B>MPlayer</B> .
67 Why are we called "brain damaged", "total asshole", "childish" by 50 Why are we called "brain damaged", "total asshole", "childish" by
68 <B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> . 51 <B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> .