No subject

[bogus at does.not.exist.com]

- "5. Do not commit changes which change behavior, defaults etc,
without asking first"
- "12. Always send a patch to the mplayer-dev-eng mailing list before
committing if you suspect that the change is going to be
controversial."
For FFmpeg, I interpret this as including API (or a new codec, or
anything). So you (Michael) should really discuss, even if it has been
discussed a year ago. If you use a proper local versioning system
(...) then this doesn't even slow you down. Extra eyes are good, as
long as we prevent bikesheddery (below).

- "13. Try to keep important discussions and requests (also) on the
mplayer-dev-eng mailing list, so that all developers can benefit from
them. IRC is good for quick discussions, but nobody is there 24/7."
I want to change this for FFmpeg, and I think most devs with me. Now
already, many smaller commits (or their "applied" counterparts on
ffmpeg-devel threads) are accompanied by "OK'ed on IRC" comments. IRC
is logged. IRC should suffice for quick patches. Particular longer /
wider discussions fit a mailinglist better than IRC.

This is all small stuff. It doesn't solve the Michael vs. Mans boxing
match. I think we need some general thought on how to decrease the
bikeshedding here, because that's likely the major problem here. You
guys are essentially taking your anger for each other into every
single ML thread where it's not relevant at all, slowing down
essentially everybody.
Let me start with an attempt to reconciliate by some examples:

- the include in avassert.h. build system is maintained by Mans & co.
This includes things like which headers to use, header paths. I mean,
seriously, Michael, do you care? Really? _Really_? I know you'll say
yes, but you shouldn't. File maintainership shouldn't turn into a
penis-length-content. Most importantly, Michael, please do understand
that Mans appears to know the C spec and related standards quite well.
We can all try to appreciate him a little more.

- the xmm clobber patch. I don't give a shit which solution we choose,
but the current behaviour is broken and two patches fix it. Mans, I'm
sorry for you, but Michael is x86 maintainer and you should leave him
to choose. You're not going to write any x86 optimizations anytime
soon so it doesn't affect you. Do you care? Really? _Really_? You
shouldn't. I should, by the way. I should've stept in. (Michael, feel
free to commit your preferred solution so we can start the final steps
to do what's right and documented in optimizations.txt. It's
embarassing that we know how to fix it and we haven't done it, still.)

- Mans, tone down on IRC. I love our discussions and appreciate the
occasional joke, but you are very hostile to Michael on IRC. Keep the
personal hostility a little more down. I think this all would be
easier if you didn't take it so personally yourself.

- Michael, please come to your senses with you general distrust
towards highly valued contributors. This includes Diego, Baptiste,
Mans and likely others. Diego already touched upon this so nothing
more needs to be said. I have full confidence that all three of them
have nothing more than FFmpeg's best interests in mind. Value them,
they are worthy.

- I volunteer to moderate technical bikesheds if you want me to. Try
to self-moderate where possible, even if you don't like each other,
you can co-exist. you are both too highly skilled to behave like
children as you did just now.

And Mans, come back (at least on IRC, if nothing else). You're dearly missed.

Ronald