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

Diego Biurrun diego
Thu Feb 10 14:31:21 CET 2011

Easy Reimar :)

On Wed, Feb 09, 2011 at 06:39:24PM +0100, Reimar D?ffinger wrote:
> On Wed, Feb 09, 2011 at 11:27:07AM +0100, Diego Biurrun wrote:
> > 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.
> WTF? Do you people even read the previous mails?
> The mail I replied to specifically said "dev with knowledge in the area",
> and I said that's not going to work.
> Then coming and saying "you're wrong, <completely other thing> will work
> just fine" is just complete nonsense.

Let me state things differently: I think you are too worried about the
general development model because you think you have found some corner
cases that are not covered (yet).

We're dealing with people, not machines, here, so no rules are meant to
be completely inflexible.  Nor are all rules finished and set in stone
yet.  Yes, we will modify processes and make things up as we go.

You already claimed that game codecs would cause big issues due to lack
of review capabilities.  Since then we have seen one new game codec
merged and another being reviewed.

The processes we propose have worked well for other projects.  That does
not mean they cannot fail for FFmpeg, but at least there is proof that
they are not destined to fail completely.  Maybe they will need some
adaptation, but nothing we cannot work out with time.

> > 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.
> And this doesn't answer as WTF one is supposed to do when simply nobody reviews
> the patches.

Ping them.  So far I think no new patches have been dropped on the floor
and we have patchwork to keep track of the ones that are missed.


More information about the ffmpeg-devel mailing list