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

[The Wanderer]

(Doesn't this discussion - the entire thing, not just this subthread I'm
involved in - belong on -dev-eng or the like by now?)


Uoti Urpala wrote:

> On Sun, 2008-05-11 at 07:33 -0400, The Wanderer wrote:
> 
>> Uoti Urpala wrote:
>> 
>>> and more important, it's not the rules which prevent people from
>>> doing harmful things.
>> 
>> No; it's the judgment and consciences of individual developers.
>> What the rules do is provide criteria, ideally gathered by
>> consensus from the developers en masse, for what to do when
>> individual developers disagree. Without rules, whenever there was
>> such a disagreement the question would have to be put to the
>> developers at large, which would result in duplication of effort if
>> the same question arose more than once and which could easily
>> result in different, er, results just based on who happened to get
>> involved each time - and which would, in any case, be quite
>> time-consuming. Gathering the answers the first time the question
>> arises (or the first time it becomes apparent that it is a common
>> question), recording them someplace 'official', and then updating
>> that record when it becomes appropriate to do so is simply a way of
>> 'caching the results', as it were.
> 
> Your view of the role of rules here seems inconsistent with your
> earlier argument that rules need to be specified in advance and a
> state of "no rules" must be avoided. If you view rules as a
> collection of precedents about how controversial issues were resolved
> in the past, meant to reduce duplication of effort when the same
> issue arises again, why would that collection have to be filled in
> advance?

It wouldn't have to - but in this case, it (at least purportedly)
already has been, viz. the written rules you seem to be saying are a bad
thing ab initio.

The case where the collection has not been filled is not a case of "no
rules", it's a case of "no indication of what the rules are" - which is
also bad, but in a different way and for different reasons.

When the rules as collected become different from the rules as enforced
and/or the rules as the community expects them to be followed, there is
again no reliable indication of what the rules are, and so either the
reality needs to be changed to match the collected rules or that
collection needs to be updated to reflect reality. In most cases, the
latter is more appropriate.

>> Note also, please, that the definition of "harm" is a complicated
>> issue, and may be considered to be very broad. By some standards -
>> of difficulty of review, difficulty of reading the commit history,
>> and I think at least one other thing I've forgotten - your own
>> commit which started this thread would be considered harmful.
>> 
>> (For that matter, by some standards any commit at all to code
>> someone else is working on could be considered harmful, because it
>> could require the someone else to do extra work to allow their
>> changes to have the desired effect - or could even render those
>> changes moot entirely. This is probably beyond the limit of what I
>> would consider valid to include in the definition, but that is part
>> of the reason to have rules to spell out where the boundaries are.)
> 
> IMO those issues are simply too complicated to be described by
> literal rules. You can't make a rule which would forbid a significant
> amount of undesirable actions without making it overbroad and also
> forbidding lots of things that should be allowed.

(Actually, you can - but the resulting text would almost certainly
constitute legalese, and even though I can read and write that sort of
thing I certainly don't think it's appropriate for all contexts; I am
therefore going to ignore the possibility for the moment.)

And that's why, no matter how important the rule, there must always be
room to allow exceptions in particular cases, in a unanimous-consent "No
objection, so ordered" sort of way.

That doesn't mean that effort should not go into attempting to ensure
that rules are not overly broad, but it does mean that there's no need
to worry about getting it exactly perfect, unless of course you're into
that kind of thing.

>>> There are already lots of harmful things you could do which are
>>> not forbidden by any rules.
>> 
>> I'm having a hard time thinking of many offhand which would not be
>> covered and prevented by the review policy...
> 
> I suppose you mean the "send patch to mplayer-dev-eng if you think
> the change is going to be controversial" part. It doesn't say
> anything about what effect (if any) the possible discussion on
> mplayer-dev-eng should have.

No, it doesn't. I suspect that it was intended to be implied as obvious
that the results of the discussion would govern the action to be taken.

It would be possible to spell out that sort of thing, but doing so is
one step closer to legalese and the legalistic mindset, which though
sometimes valuable is not really appropriate in many cases.

> If you interpret it as "every change could be controversial and
> requires getting full consensus first" then obviously a single
> developer cannot do harmful changes, but OTOH interpreted that way
> it'd have negative effects. More practical interpretations rely on
> the personal judgment of developers. If you're willing to trust the
> their personal judgment enough then you could say that a single rule
> "don't do harmful changes" would prevent anything harmful.

Except for the difficulty of defining "harm". By some lights, the
increased difficulty of review (not only in a pre-commit sense, but in a
"going back to review past changes" sense) involved in commits such as
the one which started this thread might constitute harm; by others, it
would not.

>>> Rules which even tried to cover everything would need to be very
>>> long. Removing official rules, even those rules that make sense
>>> and should almost always be followed, won't make much difference
>>> overall as most things won't be covered by them anyway.
>> 
>> "Because the rules cannot cover most things, it does not make much
>> difference whether or not there are any rules at all." I can't
>> quite identify a fallacy this corresponds to, but it just seems so
>> ludicrous to me that if you don't see what's wrong with it I'm not
>> sure there's much chance of our coming to agreement.
> 
> I don't see how you could claim that to be a fallacy.

I didn't - I said I couldn't identify one which corresponds to it. It
does look like the type of statement which I often see matched to one
fallacy or another, but that doesn't necessarily mean that it is in fact
fallacious. That does not mean that it isn't still wrong, just that if
so it would be wrong for different reasons.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.