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

[Ivan Kalvachev]

On Jan 7, 2008 12:26 AM, Reimar Döffinger
<Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> 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 ;-)

You have to prove that point of view.
Even heard about Gordian knot (wiki) ?

The solutions should always be simple. Complex solutions usually
threat only the symptoms and create more problems than they solve.


Our problem is simple. There are not enough people working on MPlayer.
So the solution is simple, we need more people working on MPlayer.

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

We have one, Diego. He is doing his best in goodwill, but it's not enough.
Unfortunately he can't code, he can't judge code quality or design,
that makes him incapable of promoting new developers on his own.

For example Carl was proposed in 3 different mail threads over one
month period by number of active developers. And yet Diego wasn't sure
enough and had to talk with every developer privately to make
decision, but he had no luck nor time. Finally KotH granted account to
Carl.
Or remember that Luca got his write account from FFmpeg first?

Diego did good job keeping the project from falling apart when Arpi
left and Alex went missing. Now the project is stable (stagnated
actually) and we need to move forward (whatever that means;) .

> The bigger question is what would be expected from such a project
> leader (no, miraculously fixing all problems is not a fair job
> description)?

Direct the project in the right direction.

As project leader you become maintainer of the whole project.
I think you are fit for the job as you do a lot of work all over
mplayer and know it well.

You don't have to fix all problems yourself, it's not one-man show.
You just have to find the people to do that and keep eye on them to do
it in proper way.


Unfortunately been arbiter is also part of the jobs description. So
far you always managed to remain calm and objective in all flamewars,
just keep it this way.  Keep focus on code and doing work.


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

You are good at what you do.
Keep doing it and make others do it in the same way.


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

Actually the 5 patches rule is the solution of both problems.
If somebody wants to become developer and he is regular contributor,
he could just say "This is my 5'th patch" and we can say "We'll be
waiting for next one", "Next time try harder", something like that or
nothing at all.

We already have private (legal,security) maillist and secret irc
channel, we'd better (re)use them instead of creating yet another.



So what do we do now?