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

[Daniel Egger]

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.

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

> 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.
 
> some of the ideas you have put forth make sense when you are working
> alone or with a tight-knit group of just a few developers all on-site
> fulltime at the same location, e.g. in a commercial setting. however,
> they do not work well with the kind of development style/cvs usage
> that has brought us mplayer. i am very amazed that a project like
> mplayer is able to work with so many developers all working on the
> live cvs tree at once -- it's fairly rare for significant bugs to be
> introduced, and very rare for the cvs version to fail to compile at
> all, unlike with many other projects. imo, part of what's made this
> work is arpi being anal about what types of patches/commits are and
> are not allowed.

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.

> finally, regardless of the relative merits of different development
> styles, you are severely lacking in social skills. you don't go butt
> into a project and tell all the current developers that their way of
> doing things is stupid -- it won't get you anywhere.

I assume that was meant for me. First of all: If I couldn't stand
mplayer I would keep my fingers out of it but instead I'm trying to
improve it. You find I'm lacking social skills? Well, better don't
read the docs then; the "we're the eleet master hackers and before
you even think about joining us consider that you won't ever be CCed
on the mailinglist you have to subscribe, cosmetic patches are not
wanted neither are refactored, clean or even clever code" - attitude
makes one more upfront, me at least.
 
Thus I have this "use the code or leave it"-attitude because I know
that people will eventually pick up good patches and get rid of ugly
code; that's called evolution.
 
-- 
Servus,
       Daniel