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

[Vittorio Giovara]

On Tue, Nov 19, 2024 at 1:55 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> Hi
>
> On Sun, Nov 17, 2024 at 11:03:35AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-11-17 01:42:20)
> > > I think this would work better than TC or nothing process.
> > >
> > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > ---
> > >  doc/developer.texi | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 78053a4623a..2af71ed749a 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -937,6 +937,9 @@ The developers maintaining each part of the
> codebase are listed in @file{MAINTAI
> > >  Being listed in @file{MAINTAINERS}, gives one the right to have git
> write access to
> > >  the specific repository.
> > >
> > > +In actively maintained areas, the maintainer has the last word in
> case of a technical disagreement.
> >
> > Strongly against.
>
> > It would lead to the project partitioning into walled
> > gardens
>
> The term "walled garden" is not correct in this context
> Walled garden refers to "Controlled Ecosystem", "Limited
> Interoperability", "Dependency Lock-In", "Selective Openness"
>
>
> > each with its own inconsistent set of rules.
>
> most 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


> 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


> 3. Some people simple and plain disagree with being under the TC (These do
> leave
>    FFmpeg or never join)
>

That's ok, people who don't follow the rules can go build their own project.


> 4. The TC is slow, this latency makes development in disputed cases just
> painfull
>    A maintainer can make a decission within minutes not the days or weeks
> the TC
>    needs. Also during this time long flame threads develop on the ML
>

As written in another email, you're putting a lot of work and
responsibility on a volunteer position, and you're unilaterally deciding
this.
Of course you get my NAK
-- 
Vittorio