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 <mich...@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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
