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

[Alban Bedel]

On Sat, 12 Apr 2008 23:55:03 +0300
Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Sat, 2008-04-12 at 21:12 +0200, Alban Bedel wrote:
> > On Sat, 12 Apr 2008 20:52:31 +0300
> > Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > > "The rules" being something which is not actually defined.
> > > svn-howto.txt (which seems to be what people talking about "rules"
> > > think contains them) neither has all the things claimed as "rules"
> > 
> > Yes, there are a few unwritten rules. Patch welcome.
> > 
> > > nor contains ONLY them.
> > 
> > And what's the big deal about it? Again patch welcome if you really
> > feel that the POLICY / RULES section deserve a file on its own.
> 
> 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?

> > > It has things nobody follows in practice.
> > 
> > Like? You are the only one who ignore those rules.
> > 
> > > It's easy to accuse anyone you want if everyone breaks some
> > > "rules" and you can pick which to enforce.
> > 
> > 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. Point 5 is about senseless warnings, the compiler is not
always right, just accept it. Point 7 (fill commit message) and 9 (ask
before touching code you don't maintain) are also respected by
everybody else afaict.

> > > Talking about "the rules" is nothing but an appeal to authority
> > > when you mean "this is different from how I'm used to doing
> > > things / like things done".
> > 
> > No, it's a set of things the team agreed upon.
> 
> 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.

> >  They can be changed any
> > time. If you don't like something just submit a patch and have it
> > discussed on the list.
> 
> There is no procedure for resolving any disagreements in case people
> on the list do not agree. And as I said I don't think any set of rules
> could really capture good practices.

As you seems to define good practices as yours or nothing else, sure
we'll never reach an agreement.

> >  But stop wasting everybody's time by knowingly
> > breaking the existing rules.
> 
> 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.

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

	Albeu