On Mon, 13 Apr 2026, 19:49 Michael Niedermayer via ffmpeg-devel, < [email protected]> wrote:
> > 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 > _______________________________________________ > ffmpeg-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] AI slop like this is forbidden for bug reports and should be forbidden on the mailing list. It's obvious you are using AI slop instead of your usual walls of text to DoS/filibuster FFmpeg developers to get what you want. This is deranged. Kieran _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
