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

[Ivan Kalvachev]

On Jan 17, 2008 1:29 AM, Diego Biurrun <diego at biurrun.de> wrote:
> On Wed, Jan 16, 2008 at 04:00:38AM +0200, Ivan Kalvachev wrote:
> > On Jan 7, 2008 12:26 AM, Reimar Döffinger
> > <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > > 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.
>
> The world's problem is simple.  People do not have enough to eat.
> So the solution is simple, we need to give people more to eat.

Your analogy is wrong in all accounts.
The world's problem is not that there isn't enough food. And obesity
is hardly a solution.

I'm well aware that not all simple solutions are correct.
It doesn't mean that a simple solution is not correct one.


> Unfortunately there is more to a solution than stating it in simple
> terms.  You need to find an effective way to put the solution into
> practice.

Of course there is more.
But once you have it, you know what steps you have to take next.
And I have even proposed the first two of them.

> > > > 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.
>
> Hardly.  At best I have (had) the responsibilities but not the
> privileges.  How I can fail in a position I never fulfilled remains a
> mystery.

You act like one by abusing your root admin position.
And I got (the wrong, I hope ) impression that you actively oppose
choosing of real Project Leader.
Would you support Reimar (or somebody else) as Project Leader?

> > So what do we do now?
>
> There is an xvmc patch in the queue.  Why don't you start by reviewing
> it?  After that I have a big mailbox full of stalled patches, take your
> pick.

That patch is rejected on same basis as the previous one.
I do have notes for full review of what have to be improved and how,
but I didn't had time to clean it up to human readable form.