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

[Uoti Urpala]

On Sun, 2008-04-13 at 00:44 +0200, Alban Bedel wrote:
> On Sat, 12 Apr 2008 23:55:03 +0300
> Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > No I don't think it deserves a separate file. Trying to make it into a
> > legal document which strictly defines what is right and what isn't
> > would require a lot of effort and the result still wouldn't be good.
> > People just need to understand it is not such a document.
> 
> You mean it contain some stuff you don't like, so we should all ignore
> it?

I mean what I said.

> > > You might want to read the rules section again. I see nothing in
> > > there that is selectively enforced.
> > 
> > The most obvious example is the "NOTE:" part of paragraph 6, which
> > tells to leave files incorrectly indented - the exact opposite of
> > what is wanted in practice. Other things which several people have
> > done differently without complaints are at least 5 (what was the last
> > complaint about a correct warning fix?), 7 and 9 (would likely have
> > more examples if the project had more people who work outside a
> > limited area, or if there was more code that is clearly "actively
> > maintained").
> 
> You might want to read again, and carefully this time. Point 6 is about
> mixing cosmetic and functional changes. This has never ever been
> tolerated.

You're wrong. Read my response to Aurelien for more details.

>  Point 5 is about senseless warnings, the compiler is not
> always right, just accept it.

But people do often fix them without "asking first" which would be
required by svn-howto.

>  Point 7 (fill commit message) and 9 (ask
> before touching code you don't maintain) are also respected by
> everybody else afaict.

There are lots of really bad and short commit messages (do you really
need examples?) and several fixes without asking.

> > Arpi originally enforced horrible development practices, which
> > probably drove away most people who already had real experience about
> > doing things right. The ones who remained either accepted such
> > practices or at least came to regard them as business as usual. Since
> > then the practices (though not so much any written descriptions) have
> > slowly moved towards more normal ones.
> 
> That's your opinion. Personally I find most of these rules make sense
> and are in fact one of the reasons why MPlayer was able to involve so
> fast. I don't deny that some stuff need updating, still it doesn't mean
> you can just ignore what you don't like.

MPlayer was able to evolve fast because it got most of the media player
attention on Linux which gave it raw manpower. Bad development practices
then led to much of the code becoming a mess and development slowing
down.

> > So how did I waste anyone's time? It's plausible that someone could
> > have a conflicting patch, but so far no one has mentioned that.
> > That's a common pattern among the cases where someone complains about
> > "breaking the rules": it's not that the commit prevented anyone else
> > from doing development, but it's the flaming about it that wastes
> > time. 
> 
> True. But what are we supposed to do when someone refuse to work as was
> agreed. Would you prefer if your svn account was just terminated
> without any warning? Hmm ... perhaps we should just have done that
> earlier.

And exactly why would you need to do anything? Whatever is your idea of
what "was agreed" why do you need to raise a fuss if someone doesn't do
things the way you want when you can show no actual problem for
development? You've done little development yourself in the last year,
except some commits during the last few days. Why is it such a problem
for you if someone does development in a different way than what you
were used to?

> > So far my commits have overall improved MPlayer.
> 
> I don't disagree, still it is a subjective opinion and it is not code
> you are maintaining.
> 
> > The complaints about not following traditional rules have not
> > achieved anything positive.
> 
> You have achieved pissing off other developers, and some responsible for
> quiet large parts of MPlayer. I'm pretty sure you don't care, it was for
> the Greater Good after all.

And you think insisting on your "rules", for the sake of following
rules, doesn't piss anyone off?