[MPlayer-dev-eng] [PATCH] Apple Remote support double click

Rich Felker dalias at aerifal.cx
Sat Sep 29 09:14:42 CEST 2007


On Fri, Sep 28, 2007 at 11:58:37PM -0400, Ergzay wrote:
> I am nitpicking here, but why is there this precedent in the first 
> place. I would think if something can be made better go for it. The 

Where “better” here means to the benefit of the patch-submitter. If
someone is trying to get a special-interest feature _they_ want
included into MPlayer, then they need to be responsible for ensuring
that it’s clean, non-buggy, and doesn’t interfere with the needs of
other users and developers.

> only reason not to I would think, is that in the svn commit log it 
> doesn't look "nice."

No, unclean patches are full of:
1) bugs that will lead to (at least) trouble later tracking them down,
   and (at worst) vulnerabilities.
2) hackish unmaintainable mess that makes it harder to add things in
   the future without someone understanding and working around the
   ugly hacks that were made.

You’re right that part of this is about looking “nice”, but a patch
that is not clear and readable is very difficult to evaluate and
audit. It’s not acceptable to have changes being committed which are
not readily checkable by everyone reading the commit log.

> Which IMHO is a pretty useless reason not to make 
> something better. I'm no developer but, from what I've seen from 
> lurking on mplayer-dev is that two of the major reasons that mplayer 
> development is so slow of late is that 1. there is resistance to change 
> from certain people and 2. patches end up getting ignored (not seen?) a 
> lot and useful features and developers go untapped. Rant complete. 
> Sorry for hijacking topic. No response needed.

Evaluating patches is hard work. Projects that don’t evaluate and just
blindly apply quickly turn into crap.

Rich



More information about the MPlayer-dev-eng mailing list