[MPlayer-dev-eng] Re: [PATCH] Development (Was: Clean up demuxers)

[D Richard Felker III]

On Tue, Feb 26, 2002 at 02:38:13AM +0100, Daniel Egger wrote:
> Am Die, 2002-02-26 um 02.18 schrieb D Richard Felker III:
> 
> > patches are supposed to be kept to a minimum and
> > make only functional changes, not cosmetic ones.
> 
> I read that but the reasoning is flawed.

if you want to believe that its fine, but you won't convince many
people here.

> > large cosmetic changes make it hard to go back and reverse patches
> > that turn out to be bad later on,
> 
> Huh? Good patches are selfcontained and wellthough. That is: You can
> go forth and back without breaking anything. If you need to backout
> a patch (which is a really rare situation, normally you simply fix
> it in case of troubles) all changes based on that patch need to be
> also to be bakked out, which makes that argument moot.

no, thats the whole point. the mplayer way -- simple self-contained
patches that do not make sweeping or widespread changes, except when
necessary -- makes it sometimes possible for older stuff to be backed
out while leaving newer changes, provided there is no dependence on
the actual change having happened. this is of course always possible
on some level, but its more feasible when you don't go doing idiotic
things like gratuitously changing variable names all over a file.

> > and its hard for developers to stay familiar with
> > their own code when someone else is reorganizing it and renaming
> > variables all the time.
> 
> a) Renaming variables is not going to happen all the time
> b) This is OpenSource development (I hope). If you want to have your
>    personal playground noone else may use: Don't do it.

you are fucking free to fork. "open source" does not mean any old
moron can jump in and make his changes to the developers' version of
the code. if you believe it does, you have some very warped ideas.

> I'm one of the core developpers of the GIMP, a much bigger project
> with more participants, also managed by CVS: breakage almost doesn't
> happen at all but the GIMP runs on a few more platforms than mplayer
> does and probably ever will which makes that even more complicated.
> Point comes now: Development DOES work that way although the developpers
> are not on-site.

wow, so that's where you get the ego. btw, last i checked, mplayer was
'bigger' by popularity, according to freshmeat. in any case, gimp is
divided into tons of plugins, which makes it much easier for many
developers to work on it at once. also, btw, gimp isn't exactly tuned
for performance...

(none of this should be taken as criticism of gimp; it's a perfectly
nice program and has different goals and design philosophy than
mplayer. i just find it offensive that you want to come here and
impose your practices on the mplayer devs.)


rich