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

[Reimar Döffinger]

Hello,
On Sat, Jan 05, 2008 at 02:01:42PM +0200, Ivan Kalvachev wrote:
> 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:
[...]
> > > 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.

Simple tends to mean wrong with complex problems ;-)

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

The XFree86 sounds to me like more of a case of a project leader actively
hindering "progress", which is very different from just not having one.
The bigger question is what would be expected from such a project
leader (no, miraculously fixing all problems is not a fair job
description)?
If you just want one for the "feel good" effect we can vote about it and
I'll volunteer for the job, though don't expect me to have much to offer
beyond what I do anyway.

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

Well, that's really a difficult topic. As I see it there are essentially
to ways to get SVN: 1) asking for it or 2) just being offered it.
Now I personally have seen very little of 1), there the question is
should this be encouraged? If yes, there probably should be a more
private way of doing it that the mailing list, not everyone likes to be
told "no" in full public...
About 2), that requires the developer being noticed - and the suggestion
in your example might not work, since if they aren't in a short time frame
at least I might never notice when someone sends the 5th non-trivial patch.

Greetings,
Reimar Döffinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080106/2f16a545/attachment.pgp>