[FFmpeg-devel] [ANNOUNCE] New FFmpeg maintainership
Wed Jan 19 15:10:50 CET 2011
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
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
- 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
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
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.
More information about the ffmpeg-devel