[MPlayer-cvslog] r26411 - trunk/libmpdemux/demuxer.c

[Michael Niedermayer]

On Sat, May 10, 2008 at 02:20:15PM +0200, Reimar Döffinger wrote:
> Hello,
> On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
> > diego           1038     504     1542
> > reimar           690     246      936
> > voroshil         312       8      320
> > nico             212      43      255
> > benjamin         144      32      176
> > ulion            153      13      166
> > eugeni           106      56      162
> > uoti              99      20      119
> > guillaume         93      24      117
> > compn             97      16      113
> > cehoyos           89       8       97
> > ivo               65       4       69
> > zuxy              55      12       67
> > vayne             14       3       17
> > corey              9       6       15
> > attila            10       5       15
> > loren             11       2       13
> > rik                1       3        4
> 
> Before anyone flames too hard: I asked for Diego to publish these
> numbers.
> The problem is, as some of those appearing later have shown, that we
> have no opinions from some important people.
> Thing is, I really want everyone to stay on this project and happily
> work together. Not sure if that is possible anymore - and in that case
> I want a more objective overview of the opinions that I currently have.
> To summarize the dilemma for me personally: I very much respect and
> agree with most of Michael's opinions, but there are a few problems:

> They basically result in a FFmpeg-style review policy. That works really
> great most of the time for FFmpeg, but I think it just can not work with
> MPlayer currently, we do not have enough people willing to do that kind
> of effort to get patches included.

ffmpegs policy text was copied from mplayers ...
besides i think the effort which would have been needed to cleanly commit
the few controversal things would not have been that huge.


> So from that perspective I do think it might be better for the long term
> good to basically let Uoti (and also other future developers) work mostly
> on their own conditions (though I seriously wish for a bit more consideration
> for other people from his side).

This attitude was what lead to the mess mplayer is currently.
Uoti can argue that the rules about indention caused bugs, sec holes and so
on but its obvious that the lack of proper reviews and rejection of bad
patches and commits was much more responsible for it.
If you now allow commits which mix cosmetics and functional changes and
other unreviewable mixes. Then this will only make mplayer a even bigger
mess than it already is.
And even if uoti never makes a mistake in his unreviewable commits,
others will follow and work under the same rules. These other people will
make mistakes and introduce many bugs.



> But: I am not ready to do this in a "let the whole team roll over to
> accommodate one developer"-style. So if it is as it looked originally
> that everyone thinks this kind of thing is a bad idea, I would never
> propose it. But now with other developers showing up with different
> opinions things are a bit different.
> Now some of you probably wonder about my completely different opinion

no iam, not surprised at all,
humans are strongly pulled toward supporting the person
"closer" to them. This has been nicely shown in various variations of milgrams
experiment if you dont belive it ...
personal talks with diego shifts ones position toward his side, ive
experienced that myself as well, I doubt it would work a second time
though :)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080510/858fb991/attachment.pgp>