[MPlayer-cvslog] r26411 - trunk/libmpdemux/demuxer.c
Michael Niedermayer
michaelni at gmx.at
Sat May 10 22:38:07 CEST 2008
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>
More information about the MPlayer-cvslog
mailing list