[FFmpeg-devel] [PATCH 2/3] doc/developer: Document how disagreements should be handled

Vittorio Giovara vittorio.giovara at gmail.com
Wed Nov 20 21:07:53 EET 2024


On Wed, Nov 20, 2024 at 1:44 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:would follow the same or very similar rules. I agree that some

> > > outliers
> > > could end with different rules. I dont think as FFmpeg grows this
> > > centralized
> > > TC system can function.
> > > The TC
> > > 1. lacks expertiese in some areas
> > >
> >
> > vague attacks on the TC should not be tolerated - either list and provide
> > examples or don't disparage elected members of the community
>
> every TC member knows every part of the project, every specification
> every architecture, every decoder, every encoder, every filter, every
> demuxer
> every muxer, every protocol, ...
>
> No, as a TC member I can tell you even though i have more authored commits
> in FFmpeg than the next few people combined. I do not know everything
>

Know thyself is my motto.
At the same time, disparaging one of the fundamental building blocks of the
community is not sound at all.


> > > 2. for a growing project there is a point where the TC cannot handle
> the
> > > cases
> > >    anymore at a acceptable quality
> > >
> >
> > you're not it, chief
>
> The TC can handle 1 case per month, if the project doubles in size it can
> handle
> 2 cases a month.
> If it doubles again, the TC can handle 4 cases a month.
> Eventually the TC can handle a billion cases a second, no problem here
>
> As the project grows, the number or maintainers grows with it. The capacity
> of the TC does not grow with it.
>

I don't think the list of maintainers is sustainable as is, let's deal with
the capacity factor problem when we get there.
It's always easy to add members to the TC, it'd be way harder to scrap it
and rebuild it like you're proposing.
-- 
Vittorio


More information about the ffmpeg-devel mailing list