This is a draft, it is work in progress but it should show the general idea.
Whats the difference between FFmpeg and Linux? The core difference in style is this: FFmpeg is relatively flat and centralized; Linux is hierarchical and delegated. In FFmpeg, patches go to Forgejo or ffmpeg-devel, get reviewed there, and once approved they are committed to the official tree. In Linux, patches are routed toward the relevant subsystem maintainers, often through subsystem-specific expectations and trees, and then flow upward by pull request toward the main tree. That hierarchy is the main source of Linux’s scalability. Below is a more detailed plan: Note in this, each stage removes bottlenecks and increases potential growth. My hope is that we do stage 1, then the project grows, then stage 2 then more growth then stage 3 and so on by the time we actually split the git repository up we are at the point where this removes a bottleneck in front of us The list below is written with LLM help from my instructions of teh process. Ive gone over it and it matches what my plan is. Just dont take each individual letter as my word, ive not checked it at that level of detail. ------Stage 1----- Turn MAINTAINERS from a loose label into the main routing mechanism. This has to come first because every later Linux-like mechanism depends on clear ownership. If FFmpeg adds integration trees, merge windows, or more automation before patch routing is clear, it will just preserve the current bottleneck under a more complicated process. FFmpeg already has MAINTAINERS and says maintainers of parts of the codebase are listed there; Linux goes further by using MAINTAINERS as an operational map, with fields for maintainer, reviewers, mailing list, subsystem profile, and SCM tree, plus get_maintainer.pl to route patches. FFmpeg should copy that operational aspect first: every significant directory or subsystem should have a primary maintainer, backup maintainer or reviewer set, expected response behavior, and explicit fallback when the maintainer is inactive. Why first: ownership is the prerequisite for delegation. Benefit: review load stops being one large shared queue and becomes many smaller queues. FFmpeg vs Linux here: FFmpeg already has maintainers, but Linux uses them much more aggressively to decide who must look at what. ------Stage 2----- Add per-subsystem "entry profiles" or house rules. Once ownership exists, each subsystem should publish a short process note: what kinds of tests are mandatory, what benchmarks are expected for hot paths, what spec references are required for bitstream/container changes, what sample material is needed, and what cross-subsystem reviewers must be CCed for API or ABI changes. FFmpeg already has a strong global checklist and testing expectations; Linux adds subsystem-specific profiles because one global checklist stops scaling once areas diverge in risk and custom. Why second: rules only become credible when there is a named maintainer responsible for enforcing them. Benefit: less repetitive debate, faster reviews, easier onboarding, clearer expectations for contributors. FFmpeg vs Linux here: FFmpeg’s process is comparatively uniform; Linux scales by allowing local process variation within a common global framework. ------Stage 3----- Move active subsystems to maintainer trees, but only for non-trivial work. This is the first real structural Linux step. FFmpeg’s docs already say that if review is slow, somebody willing to take over an area can maintain that area and FFmpeg will merge each area from where it is best maintained. That is already very close in spirit to Linux maintainer trees. The next move is to formalize it: codec families, containers, filters, hwaccels, lavu internals, FATE, and security-sensitive parser areas should gradually get public staging branches or trees. Small obvious fixes can still go directly to master after review; larger series should land in the relevant maintainer tree first. Linux’s subsystem maintainers commonly stage patches in their own trees and then send pull requests upward. Why third: maintainer trees only work after routing and subsystem rules exist. Benefit: parallelism. Multiple maintainers can absorb, revise, and batch work simultaneously instead of serializing everything through one shared path. FFmpeg vs Linux here: FFmpeg review is still centered on one shared discussion surface ending in direct commits; Linux distributes integration itself, not just review. ------Stage 4----- Create an ffmpeg-next integration tree before changing release cadence. This is the biggest single scalability win after maintainer trees. Linux relies on linux-next as a preview of what mainline is expected to look like after the next merge window, and the docs say it has become integral to the process. FFmpeg should do the same in lighter form: a continuously rebased or regularly regenerated integration tree that merges active maintainer trees, runs broad CI/FATE/sanitizers, and catches cross-subsystem conflicts before they hit master. For FFmpeg, this matters especially because cross-cutting multimedia changes often touch demuxers, parsers, codecs, bitstream filters, CLI behavior, docs, and FATE together. Why fourth: once work is split across trees, you need a convergence point to detect interactions. Benefit: fewer late merge conflicts, fewer breakages on master, earlier detection of semantic conflicts between subsystems. FFmpeg vs Linux here: current FFmpeg process is closer to "review then commit"; Linux inserts a large pre-mainline integration stage. That is a major reason Linux can scale socially and technically. -----Stage 5------ Only after that, introduce a light fix-vs-feature split and possibly a small merge window. This is where many projects start, and it is usually the wrong starting point. A merge window without subsystem maintainers and an integration tree just creates deadline pressure, rushed review, and politics. In Linux, the cadence works because subsystem trees already exist, fixes and new development are often separated by tree, and the integration machinery is mature; for example, the networking process explicitly distinguishes net for fixes and net-next for new work. FFmpeg could adopt a milder version: keep urgent fixes flowing continuously, require new features and larger refactors to go through maintainer trees and ffmpeg-next, and reserve specific parts of the cycle for feature pulls into master. Why fifth: cadence controls are downstream of structure. Benefit: calmer stabilization periods, less churn near release work, easier backporting, fewer “big series lands at the worst possible time” problems. FFmpeg vs Linux here: FFmpeg today is more continuously merged; Linux’s time-bounded integration works because delegation and pre-integration are already in place. ------Stage 6----- Formalize escalation, inactivity, and replacement rules for maintainers. Linux’s maintainer framework scales partly because it has explicit statuses and well-understood escalation paths when an area is unmaintained or a submaintainer is unresponsive. FFmpeg should define objective rules: when a maintainer is considered inactive, when a co-maintainer can take over, when cross-subsystem arbitration is needed, and when higher-level project governance steps in. This keeps the system from depending too much on individual personalities. Why last: governance rules are much easier to write once the operational model is already visible in practice. Benefit: continuity, less social friction, and less risk that subsystemization simply creates new bottlenecks. FFmpeg vs Linux here: FFmpeg has maintainership, but Linux has a more explicit maintenance-state vocabulary and escalation culture. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
