[FFmpeg-devel] [ANNOUNCE] New FFmpeg maintainership

[Cyril Russo]

Le 18/01/2011 23:47, Anders Gr?nberg a ?crit :
> Why couldn?t you have forked, or held a vote?
> I cannot see how conspiring and stabbing Michael in the back was a
> good way of handling it.
I don't think it's worth using such violent / politic semantic in your 
answer.
This is no murder, no stab, no coup d'?tat, no dictator here.

 From what I currently understand by reading this list, posted patches, 
proposed comments, I can only assert these things:
- Michael is prone to arguement, discouraging casual developers from 
working/improving ffmpeg.
- Michael leads the project in a direction that, after much time, take 
sense, even if there are so many people left on the road.
- The rules and technical level required is not the same for the casual 
developers than it is from actual maintainers (read, it's easier for a 
maintainer to actually get his code included, even if less featured)
- A lot of discussion happens on ridiculous things, and a lot of 
important change are delayed to the day after the end of the world.

I understand there is some recuring illness here, and at least I 
congratulate people for acting, instead of lurking to their own navel.
BUT, but, please while there is still some power in the wind of change, 
try to filter the best and dump the bullshit.

For example, I think these rules should be relaxed, so the entry-level 
recruitment is larger:

1) TAB / SPACE / trailing whitespace. Actually, rejecting a patch that 
can be filtered with a simple "sed" command to fit your standard is 
really painful, both for the author and the maintainer. Set up a commit 
hook, record a macro on your favorite text editor, but don't complain 
about this.

2) cosmetics changes and code. While it's easy to understand the rule 
about this, really it's a pain for the developer to actually rework his 
patch not to include cosmetics changes. I'll speak for myself, but I do 
understand a code when it's correctly indented, but I don't when it's not.

3) Documentation proposal should not be rejected if no documentation 
exists already. One developer = one voice, and it's actually not 
possible to suit them all. So at least a non-perfect documentation is 
better than no documentation at all. The documentation of ffmpeg is so 
bad that people use tutorials from 2006, repeating the same errors 
endlessly.

4) More generally, when a maintainer propose a better alternative for a 
reviewed patch, (s)he could commit/change the patch him/herself and 
don't have to let the initial developer fix it. There is more time 
wasted in useless feedback loop (writing mails to say it lack a space 
here or here), so that in the end, the original idea is not applied at all.

Michael, I think, his very important for this project, he is smart and 
experienced, and I think he has his place in the maintainer team.
But, he should release/delegate some of his power to others so he could 
concentrate on where his compentencies are better suited, like in patch 
review, optimizations, refactoring.

Regards,
Cyril