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

[Diego Biurrun]

On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
> On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
> > On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
> > > On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger
> > > <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > > > On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
> > > >> diego           1038     504     1542
> > > >> reimar           690     246      936
> > > >> voroshil         312       8      320
> > > >> nico             212      43      255
> > > >> benjamin         144      32      176
> > > >> ulion            153      13      166
> > > >> eugeni           106      56      162
> > > >> uoti              99      20      119
> > > 
> > > Reimar, looking at these numbers, I'd say that you are de-facto project leader.
> > > Diego is not coder and none of his commits changes the way MPlayer
> > > works. He is doing a lot of refactoring and cosmetics.
> > > 
> > > Reimar, please take the Project Leader role and resolve the situation
> > > in the way you like it.
> > 
> > yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
> 
> I will write up a statement/explanation before the weekend draws to a
> close.  I have no time right now because I am meeting friends in a few
> minutes.

Sorry, this took much longer than promised.  I was very busy these past
weeks and days and was away for a week without internet in between.
Admittedly, I also always get carried away by maintenance duties and
random issues.  Probably also due to the fact that my motivation to
flame is at an all-time low.  Coding feels so much more fulfilling...

I'm also very much torn between the desire to write this statement as
promised and the fear (or rather certainty) that this will stir up
flaming again and cause grief and time loss.

Since I very much feel that everybody should try to look at the
situation again with a cool head and not let emotions cloud their
judgement, this long period of calm might not be such a bad thing
in the end.  We shall see. 

Anyway, here comes my position statement:

Everybody should step back for a minute, calm down, and think about what
it really is that we were debating:

Uoti committed a bunch of cosmetic cleanups of different types together
and labeled his commit as "indent".  That was not good and I dislike bad
commit messages more than the next guy, but it was not catastrophic.
Plus, it was neither malicious, nor intentional.  Uoti honestly did not
expect this to be controversial.

Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer
standards, erupts.  I speak with Reimar, I speak with Uoti, Reimar
eventually calms down again.  As suggested by me, Uoti speaks with
Reimar, they decide to find a way to work better together with less
friction.

Everything should be fine and dandy again, should it not?  No, wait, of
course flaming has not subsided, but reached epic proportions instead.
The tides of the discussion go ever higher and none of the participants
is helping it in any way.  On the contrary, all sides are stubborn or
prone to flames or both and generally have a number of character traits
not conducive to resolving conflicts.

But what has really happened?  Whatever you may think of the policy, it
does not contain a paragraph that forbids committing different types of
cosmetic changes together.

In fact, we had a precedent for a similar commit about half a year ago:

------------------------------------------------------------------------
r24911 | uau | 2007-11-01 07:51:38 +0100 (Thu, 01 Nov 2007) | 4 lines
Changed paths:
   M /trunk/libmpcodecs/dec_audio.c

Reindent dec_audio.c
Also remove some commented out code
------------------------------------------------------------------------

No big controversy arose out of that one, nor was there reason to.

There should be no reason now.  The commit message has been fixed.  Uoti
had no malicious or trollish intent and has promised to mention such
things in commit messages in the future.  That said, he really is the
last person that can be accused of writing bad commit message in
general.

If somebody wants to insist on separating cosmetic commits piece by
piece, be my guest to do it yourself.  I single-handedly reindented and
prettyprinted all of FFmpeg to make it conform to the coding style.  I
know very well how much work and how little fun this is.  I diligently
split stuff myself, but I do not require the same level of pedantic
attention to detail from others.


I have been accused of abusing my powers.  Let's face it, I am regarded
as the de-facto project leader, I have heard it many times in private.
Plus, in situations like these, I get treated as bearing all the
responsibilities of a project leader - with no privileges.

I am not trying to lament here, just stating facts.  Leadership requires
standing up and not following loud voices in the direction of least
resistance.  This is such a situation.

We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for
Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin,
Diego).  This is a far cry from a clear situation, especially given that
each of the latter 4 is more active than all of the 5 combined.

Notwithstanding the fact that I am not a fan of voting procedures to
resolve conflicts in projects like this one, democratic voting procedures
need to be fixed before the actual voting takes place.  We would have to
know who is eligible to vote (why should Uoti not be eligible?), what the
required majorities are and what number of votes constitutes a quorum.

As Michael said, I prefer to work in projects where the developers get
to steer the direction of the project.  But, let's face it, developers
are not all equal, some are more active and/or more experienced and/or
more merited than others.

I applaud Benjamin's humility when he says that he does not consider
himself in a position to vote here because he has not been active enough
as of late.  I wish more people were so humble, so hard-working and so
averse to flaming.

Nonetheless we have maneuvered us into a Mexican standoff.  There is no
way to satisfy everybody in this lose-lose situation and especially I
can only choose between damaging my reputation in different ways.

I cannot give in to the wishes of a vocal group of merited, but inactive
developers.  Nowadays other people do the heavy lifting on MPlayer.
They should get to decide how the project works in exchange.  Reimar
has not voted in favor of removing Uoti's account; the voices of many
active developers have remained mute.

I do not wish to alienate anybody, but I have to think about the
long-term well-being of the project.

This projects has many problems, but renegade commits are not one of
them.  Lack of manpower is much more serious as is the constant flaming,
intransigent insistence on minority standpoints and architectural issues
in the codebase.  Flaming a developer that works on architectural issues
out of the project is not the way forward.

We are not Linux kernel and we are not a wealthy company.  We have very
limited manpower and we cannot just go out and hire the people we want
and need.  We have to be content with whomever we've got aboard and
with whatever skills and personality they have got.

Let's face it: competent developers do not joing MPlayer every month.
On the contrary, they are few and far between; a resource not to be
squandered.  If they happen to be difficult to work with (and we have
many of those aboard), we have to find ways to make ends meet.

Conflicts need to be mitigated and resolved, not fought out.  The
imperative should be to work constructively together and give each
other a bit of leeway and the benefit of the doubt.

This is what I attempted to do in this situation.  I successfully
mediated between Reimar and Uoti, which is where the problems
originated.

Extra parentheses in return statements will not be a source of problems
again in the future, because I removed all of them.  The same could be
achieved with regard to indentation, it would just require some
willingness to compromise from all sides.  From then on, nobody would be
able to step on any toes with cosmetic commits.

Uoti's commits were reverted, but nobody bothered to recommit them.
This way, everybody loses.  I split the commits to make everybody happy
and to improve the code, because this is what we should really strive
for.

I don't mind splitting a commit or two in the future, just as I - just
to give an example - never minded writing documentation when Michael
skipped that in his commits.  Then just as now, shouting "policy
violation", reverting commits and leaving things at that only makes
things worse.

MPlayer is not developed in a mail or IRC client, it is developed in
a text editor.  Flaming does not improve MPlayer as a project or as a
codebase, on the contrary.  It wastes precious time, makes everybody
unhappy and people go find a different project to spend their time on.

The constant flaming *must* end.  I was very close to burnout during
this conflict and had very much decided to pack it all in for good.
Trying to work on MPlayer surrounded by people who appear to enjoy
flaming more than coding and are stubborn and intransigent stops
being fun at some point.  Everybody (and i mean everybody) seemed
to have gone mad.

Sleeping things over and concentrating on coding instead of flaming does
help, however.  As I said earlier, please look at the issues again with
a cool head and do not let emotions cloud your judgement.

Diego