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

[Uoti Urpala]

On Fri, 2008-05-09 at 02:22 +0200, Aurelien Jacobs wrote:
> Uoti Urpala wrote:
> 
> > On Wed, 2008-05-07 at 10:58 +0200, Nico Sabbi wrote:
> > > it seems obvious and simple to me: many developers against one
> > > asked Uoti's suspension, thus Uoti's account should have been
> > 
> > You think no one else would be against it? Really? Not even myself?
> 
> Do you seriously mean you should be allowed to vote against your
> own account revocation ? Funny :-)

Yes (even if there was a real vote, which the flaming has not been). A
voting system which worked otherwise would have nasty problems. Consider
a project with two developers. By your system both would have an
overwhelming majority to expel the other. Or consider a vote to revoke
multiple accounts. Either you'd inconsistently allow the the targets to
vote now, or it would be possible to exclude a set of people from voting
(in the extreme case a single developer proposing to expel everyone else
and being the only one eligible to vote).

> > Even considering only the posted opinions, if you add just me to the
> > public "against" side and then compare what each side has actually
> > done for MPlayer during the last year which side do you think has
> > done more?
> 
> Huh.. I fail to see how relevant this could be !

You think it's completely irrelevant who does actual development? And I
did give more explanation in the following sentences.

> > I think the suspension requests are in a pretty clear
> > minority by that metric.
> 
> One can always find a metric which suits his own needs,
> whatever the issue is.

If you have reasons why another metric would be better then state them.
Making insinuations like your statement above is cheap rhetoric without
any actual content.

> > And if you think that's not a fair metric,
> 
> Obviously I do.

Then which one is better? A pure head count even if it means there are
the people who actually do things and others who interfere with work
while doing little themselves?

> > it's IMO a much better one than head count to predict which half of a
> > project will be successful if people do consider the issue a "my way
> > or I quit/fork" one.
> 
> Do you think other developers will quit/fork if your account is
> revoked ? Or do you think you've done more for mplayer than
> every other developers ?

How many do you think will quit/fork if it is not revoked? I think I can
do more for MPlayer than the people likely to quit. Plus I expect it to
be easier to get new developers if there are less people with your
attitude around.

> > Even knowing the unusual tastes of some MPlayer developers I did not
> > expect those commits to cause such controversy.
> 
> You know very well that it's not only about those commits.
> It's about your constant refusal to follow commonly accepted rules.
> You are even denying that there are some commonly accepted rules.
> And you seem to deny that some kind of rules are necessary to
> do collaborative work.

Rules which override common sense are not required, nor rules that are
enforced "because they're rules". Breaking a "rule" is never a reason to
revert a commit, much less demand someone be expelled from the project,
if you can't show actual harm independently of the rules.

MPlayer does not have rules that could be enforced literally. I already
gave examples why svn-howto.txt is not suitable for that earlier.

> This kind of mentality is incompatible with having an svn account.
> And this is clearly explained in svn-howto.txt:
> 
>   What follows now is a basic introduction to Subversion and some
>   MPlayer-specific guidelines. Read it at least once, if you are
>   granted commit privileges to the MPlayer project you are expected
>   to be familiar with these rules.
> 
> Well, the wording may be a bit loose, but this just mean that
> accepting an svn account implies accepting written rules. Thus
> refusing those rules means you refuse your svn account.

svn-howto.txt is not a binding constitution that would define what
having an svn account means. And as I already explained earlier you just
CANNOT interpret the "rules" in that file literally. You're selectively
choosing what you try to enforce.