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

[Uoti Urpala]

On Sat, 2008-05-10 at 22:38 +0200, Michael Niedermayer wrote:
> On Sat, May 10, 2008 at 02:20:15PM +0200, Reimar Döffinger wrote:
> > 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.

IMO what caused much of the existing ugliness was adding features in a
minimally invasive way as hacks on top of existing code when more of the
existing code should have been rewritten to make an overall consistent
system. Anyway the current problem is not that any particularly ugly
code would be added but that there is lots of old code which is
significantly worse than anything new and needs to be cleaned up. Trying
to polish minor details of commits or nitpicking about them is not a
good use of time when there are much more significant problems to fix in
the existing code.

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

I don't agree with claims about my commits being "unreviewable", and I
doubt people in many other projects would make such claims. MPlayer has
historically had extremely strict practices in some areas such as
separation of whitespace changes and very lax ones in others such as
commit messages.

I think it's completely ridiculous to claim that my commits would make
MPlayer worse than the existing code.

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

I don't agree about my commits being "unreviewable", but I do make
changes that an "average" developer probably shouldn't attempt. However
I don't think I should avoid them just because someone else is likely to
fail if they try to do the same, and I don't really see that as a big
practical problem.