[MPlayer-cvslog] r24941 - trunk/mplayer.c

[Uoti Urpala]

On Mon, 2007-11-05 at 19:53 +0100, Michael Niedermayer wrote:
> On Mon, Nov 05, 2007 at 04:16:25PM +0200, Uoti Urpala wrote:
> > Breaking gcc 4+ would not be "ignoring the rules" (no project should
> > need an explicit rule against things like that), it would be just
> > idiocy.
> 
> idiocy like breaking gcc 2.95 support? like commiting unreviewable changes?
> yes its similar you have my agreement

gcc 2.95 has not been maintained for something like six years. It's not
available in major Linux distributions any more (oldest gcc in Debian is
3.3; I'm not that familiar with Fedora, but a look at a Fedora mirror
showed the explicitly not supported Red Hat 2.96 as the oldest available
gcc compatibility version, making 3.2 the oldest gcc version which could
possibly compile MPlayer). And so on. Comparing not supporting gcc-2.95
with breaking the current gcc is just absurd.

> > > a few other people would think that macosx and win32 support are against their
> > > free OSS philosophy and would thus break them
> > 
> > Intentionally going out of your way to break support which wouldn't
> > affect you otherwise is very different from not willing to work in a
> > limited subset of the basic language to support an obsolete compiler. If
> > macosx and win32 support were implemented in such an invasive way that
> > most functions everywhere would have #ifdef WIN32 blocks then I'd
> > actually understand people not willing to keep updating those when
> > they'd change the functions.
> 
> if we had #ifdef GCC295 in every function id vote for droping that support
> at once as well, but thats not the case

There are no #ifdef blocks but it still breaks from changes in just about any function.

> also i think our policy does say that people cant randomly commit to 
> code they dont maintain

I hope not too many people insist on that any more. Strict code
ownership is not a good development policy.