[FFmpeg-devel] [PATCH] Update MAINTAINERS

[Michael Niedermayer]

Hi

On Wed, Nov 20, 2024 at 06:26:25PM -0500, Vittorio Giovara wrote:
> On Wed, Nov 20, 2024 at 6:20 PM Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> 
> > Hi
> >
> > On Wed, Nov 20, 2024 at 04:12:39PM -0500, Vittorio Giovara wrote:
> > > This giant list of people who may or may not be active or agreeing to the
> > > full new rules of the maintainer role overstayed its welcome. It's time
> > to
> > > call things as they are.
> > > ---
> > >  MAINTAINERS | 553 +---------------------------------------------------
> > >  1 file changed, 4 insertions(+), 549 deletions(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 8a1883c48c..3dd9b6d671 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -1,556 +1,11 @@
> > >  FFmpeg maintainers
> > >  ==================
> > >
> > > -Below is a list of the people maintaining different parts of the
> > > -FFmpeg code.
> > > +There is only one maintainer in FFmpeg, the Technical Committee, tasked
> > > with
> > > +resolving issues among developers, and defining the area of
> > improvements in
> > > +the codebase.
> > >
> > > -Please try to keep entries where you are the maintainer up to date!
> > > -
> > > -*Status*, one of the following:
> > > -[X] Old code. Something tagged obsolete generally means it has been
> > > replaced by a better system and you should be using that.
> > > -[0] No current maintainer [but maybe you could take the role as you
> > write
> > > your new code].
> > > -[1] It has a maintainer but they don't have time to do much other than
> > > throw the odd patch in.
> > > -[2] Someone actually looks after it.
> > > -
> > > -A (CC <address>) after the name means that the maintainer prefers to be
> > > CC-ed on
> > > -patches and related discussions.
> > > -
> > > -(L <address>) *Mailing list* that is relevant to this area
> > > -(W <address>) *Web-page* with status/info
> > > -(B <address>) URI for where to file *bugs*. A web-page with detailed bug
> > > -              filing info, a direct bug tracker link, or a mailto: URI.
> > > -(P <address>) *Subsystem Profile* document for more details submitting
> > > -              patches to the given subsystem. This is either an in-tree
> > > file,
> > > -              or a URI. See
> > > Documentation/maintainer/maintainer-entry-profile.rst
> > > -              for details.
> > > -(T <address>) *SCM* tree type and location.
> > > -              Type is one of: git, hg, quilt, stgit, topgit
> > > -
> > > -
> >
> > I object to this
> >
> 
> Why? Please elaborate why you find this useful and why we can't delegate
> the TC

I think the explanation below is quite intelligent.

Why Open Source Projects Need a Maintainer File
Clear Accountability for Subsystems

    FFmpeg, like other large open-source projects, is divided into multiple subsystems (e.g., codecs, demuxers, muxers, filters). A maintainer file assigns responsibility for these components to specific individuals or teams.
    Maintainers ensure the health and functionality of their assigned areas, handling bug fixes, code reviews, and updates efficiently.

Facilitating Contributor Collaboration

    Contributors, especially newcomers, need to know who to contact for guidance or patch submission. The maintainer file provides a direct mapping of areas of responsibility to individuals, avoiding confusion and delays.

Efficient Patch Review and Merging

    Patches in FFmpeg often need specialized knowledge for review. The maintainer file ensures patches are sent to the right people with the necessary expertise, speeding up the review process and reducing the risk of introducing bugs or regressions.

Decentralized Development Model

    Large projects like FFmpeg rely on decentralized development to manage their scale. The maintainer file empowers individual contributors to focus on specific areas, enabling the project to grow and evolve without overwhelming any single person or team.

Continuity and Historical Context

    A maintainer file provides a clear record of who has been responsible for specific components over time. This helps identify historical decisions, locate expertise, and transition responsibilities when a maintainer steps down.

Addressing Areas Without Active Maintenance

    By listing all maintainers and their responsibilities, the project can identify areas that lack active maintainers, encouraging the community to recruit new contributors or prioritize efforts in those areas.

Why a Technical Committee Cannot Replace a Maintainer File
Scalability of Decision-Making

    A technical committee operates at a high level, focusing on strategic decisions and project-wide policies. If it had to review all code or oversee all areas, it would quickly become overwhelmed. Maintainers handle the day-to-day management of specific components, allowing the technical committee to focus on broader issues.

Specialized Expertise

    Maintainers often have deep, specialized knowledge of the subsystems they oversee. A technical committee, composed of generalists or experts in different areas, may lack the detailed understanding needed for efficient review and decision-making in all cases.

Avoiding Bottlenecks

    A technical committee would create a bottleneck if it were solely responsible for all decision-making, leading to slower patch reviews, delayed bug fixes, and less agile development. Delegating responsibilities to maintainers ensures the project can progress more smoothly.

Encouraging Community Participation

    Maintainers are often active developers deeply engaged in the community. Their involvement encourages contributors to interact and collaborate with them directly, fostering a more vibrant and inclusive development environment. A technical committee might feel more distant or inaccessible.

Distributed Authority

    Open source projects thrive on a distributed model of authority. While a technical committee provides governance and oversight, maintainers handle the operational responsibilities within their domains, ensuring checks and balances within the project.

Continuity in Specific Subsystems

    Technical committees often rotate members or focus on high-level issues, which could lead to discontinuity in oversight of specific subsystems. Maintainers ensure long-term consistency and expertise within their assigned areas.

In summary, a maintainer file is critical for organizing responsibilities, ensuring accountability, and enabling efficient collaboration in open-source projects like FFmpeg. A technical committee complements maintainers by focusing on governance and high-level decisions but cannot replace the specialized, hands-on role that maintainers play in managing the project’s day-to-day technical needs.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241121/6cfcb7a2/attachment.sig>