[FFmpeg-devel] [VOTE] Equality and leader team

Diego Biurrun diego
Wed Feb 9 11:27:07 CET 2011

On Wed, Feb 09, 2011 at 11:15:44AM +0200, Felipe Contreras wrote:
> On Sun, Feb 6, 2011 at 9:31 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > On Sun, Feb 06, 2011 at 02:03:08PM -0500, Justin Ruggles wrote:
> >> For the record, I'm not against more developers having commit access as
> >> long as we still require patches be sent to ffmpeg-devel and approved by
> >> at least one other dev with knowledge in the area
> >
> > I'll repeat it again: this is ridiculous. There are vast areas of FFmpeg
> > with 0 to 1 devs with knowledge. This makes maintaining these parts
> > _impossible_!!
> You don't have to have prior knowledge on the area to Ack a patch. It
> is highly preferable, but if there's nobody else, just some basic
> sanity checks should do it. Hopefully in the process of ack'ing a
> patch, the developer would take the task try to understand the code
> before doing so, and that's always good.

Thanks for (once again) stating clearly what seemed obvious to me/us.

The new review policy is not designed to facilitate denial of service
attacks against development progress.  Every change should get a set
of qualified eyes that verify it.  This should be done on a best-effort
basis for a reasonable definition of qualified.

For example, nobody knows the build system quite as good as Mans.  That
does not mean that nobody else can review or ack his patches.  Still
other people like me can look at his changes and determine that they do
the right thing.

In a perfect world an ACK would be given by a person at least as
qualified as the original devloper.  For many areas of FFmpeg we have
this kind of manpower available.  In areas like Tobias Bindhammer's C64
encoder it is clear that we cannot provide the same review quality as
in the build system or the networking code.

But the corollary is not that reviews should be skipped in this case or
that code can never get committed.  Instead we try to do our very best.
Sometimes that can only mean basic sanity checks, yet it's valuable
nonetheless because everybody slips up once in a while.


More information about the ffmpeg-devel mailing list