[MPlayer-cvslog] CVS: main configure,1.1196,1.1197

[Diego Biurrun]

On Fri, May 12, 2006 at 06:34:14PM +0300, Ivan Kalvachev wrote:
> 2006/5/12, Diego Biurrun <diego at biurrun.de>:
> >> And Diego is not the person who can decide this kind of stuff. We've
> >> always tried to do our best to write the most portable code and
> >> support as many architectures as possible.
> >
> >I'm the maintainer of the build system, who else can decide this kind of
> >stuff?
> 
> I did check when you become a maintainer, of course you promoted it
> yourself 6 months ago, and haven't even asked if somebody else want to
> maintain it. Until then configure was collective effort and nobody got
> veto on it.

That's a joke, right?  I have been maintaining it for much longer than
that, just look at the CVS logs and see how many patches I have reviewed
and applied.  At some point I listed myself as the maintainer since I
had been doing the job for a long time already and I know the build
system quite well.  Also, this is common practice as stated at the top
of the MAINTAINERS file:

  Everyone is free to nominate himself/herself for a maintainership.

You're speaking as if we had people competing with each other for that
post, while nothing could be further from the truth.  For most parts of
the code we are happy if we can find a maintainer at all, not to talk
about an active one.

To give you an idea:

cerebus:~/src/mplayer/main$ cvs log configure | grep "author: iive" | wc -l
22
cerebus:~/src/mplayer/main$ cvs log configure | grep "author: diego" | wc -l
152

Only Arpi has more commits to configure than I do.

The build system *is* one of the few well-maintained parts of MPlayer.
If there are complaints, I haven't been hearing them.  If there are
overlooked patches, point me at them, I will review them.

> Well, I can say I really feel safe when maintainer is the person that
> "... won't reject a patch that shaves more than 150 duplicate lines
> from the FFmpeg build system on the grounds that it (temporarily)
> breaks MPlayer. " and of course then not fixing it (another dev fixed
> it about week after that).

Nonsense, I wanted to discuss the proper solution.  There was a very
simple known workaround, copying over common.mak from FFmpeg along with
the subdirs.

Diego