[MPlayer-cvslog] r25521 - trunk/libmpdemux/demux_ogg.c

[Ivan Kalvachev]

On Jan 4, 2008 6:29 PM, Diego Biurrun <diego at biurrun.de> wrote:
> On Thu, Jan 03, 2008 at 02:50:18AM +0200, Ivan Kalvachev wrote:
> > On Jan 3, 2008 12:53 AM, Balatoni Denes <dbalatoni at interware.hu> wrote:
> > > Wednesday 02 January 2008 21:01-kor Diego Biurrun ezt írta:
> > > > On Thu, Dec 27, 2007 at 03:10:07PM +0100, Balatoni Denes wrote:
> > > > > Thursday 27 December 2007 12:44-kor Diego Biurrun ezt írta:
> > > >
> > > > There is no doubt that contributing to MPlayer can be a slow and tedious
> > > > process.  However, I disagree that this is a question of attitude.  It
> > > > is a matter of manpower.  We receive around an order of magnitude more
> > > > patches than we have time to review.
> > >
> > > You are perfectly right that manpower is an issue. But I am also critical of
> > > the reviewing process, where each patch is picked apart to it's last letter.
> > > I think it would be suffcient to point out blatant errors, and violations of
> > > (preferably written) policy - but not force the contributor into compliance
> > > in every minor (sometimes subjective) issue. It would be a form of generosity
> > > towards the contributor if you wish, and without mentioning the obvious
> > > advantages imho it also wouldn't lead to any visible or practical degradation
> > > to the quality of the codebase (we are talking about the mplayer codebase
> > > here afterall). I am sure that this point is controversial to many of you -
> > > but this is the compromise and attitude I have mentioned before.
> > >
> > > > So what do you call potential developer?  More contributors we do not
> > > > need, there are more than we can handle already.  What we need are more
> > > > reviewers, but these are extremely hard to come by.  Very few committers
> > > > review patches, much less outside their area of expertise.
> > >
> > > More reviewers would of course be needed. However I don't think that a normal
> > > open-source project would ever be wishing for less contributors. Better
> > > contributions maybe, but definietly not less.
> >
> > It's kind of egg and chicken dialema.
> > More reviewers means more developers, and you can become developer by
> > having frequent and good contributions, but you can't pass your
> > contributions because there is nobody to review them. And because
> > there is nobody to review them there won't be any reviewers.
>
> No doubt about this, is it enough to motivate you to review a patch
> every once in a while?
>
> > MPlayer project have serious issues from very long time. One of them
> > is the non-transparent and very stagnated way to promote new
> > developers.
>
> That's unhelpful.  What we need are suggestions on how to improve
> things.

Simple.

1. Having somebody who can distinguish bad from good code for Project
Leader would be good start. Usually it is the Project Leader who
invites new developers (or removes misbehaving ones).
If the project is suffering then usually it is Project Leader's fault
and he should be replaced. It made miracles for xfree86/xorg.

2. I won't mind having some simple guidelines for promoting
contributors to developers.
For example: five non-trivial patches or 1 big module, committed
without (requesting) non-trivial changes. Maybe also asking for
agreement of the developers who have committed the patches in
question.