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

[compn]

On Fri, 30 May 2008 03:04:14 +0200, Diego Biurrun <diego at biurrun.de> wrote:
>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


basically, mplayer needs a project leader to solve this issue quickly. also to kill off some of the flames and trouble that the project has suffered :)

is anyone opposed to reimar as project leader?

-compn