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

[Uoti Urpala]

On Sat, 2007-09-29 at 22:05 +0200, Diego Biurrun wrote:
> On Fri, Sep 28, 2007 at 11:58:37PM -0400, Ergzay wrote:
> > > 2007/9/28, The Wanderer <inverseparadox at comcast.net>:
> > >> Comment fixes (at least ones which do not change the effective meaning
> > >> of the comment) are still cosmetic, and I believe there is precedent 
> > >> for
> > >> them being applied separately.

> > 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 
> > only reason not to I would think, is that in the svn commit log it 
> > doesn't look "nice." 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. 
> 
> What we lack is reviewers, not people sending in patches.  So we need to
> shift as much work as possible away from the reviewers.  It boils down
> to this in the end.

I wouldn't say there's a lack of reviewers in general, but rather for
some specific areas. MPlayer has a lot of loosely coupled features and
most people only use a limited subset. If few developers ever use the
affected features then they won't have much motivation to review changes
either.

I agree with Ergzay that complaining about things like some isolated
comment changes is pointless nitpicking which is only likely to piss off
patch submitters. If that's the only comment you can make about a patch
which has more substantial changes then it's better not to post at all.
I don't consider separating minimal related cosmetic changes a good idea
anyway; even if one patch is slightly simpler the drawback of having
twice as many commits is much bigger than the benefit.