DevNews

GNOME RFCs and extension quality are separate tracks

On this page
  1. A proposal is not an adopted project-wide rule
  2. A small lifecycle example explains the cost
  3. Two different review records

A governance discussion and an extension-review reference appeared in the same week. They address related maintenance problems, but one did not automatically become the policy of the other.

Conceptual extension lifecycle: enabling creates a timer and retains its identifier; disabling removes the source and clears the reference before another enable. Hiding the panel alone leaves the timer lifecycle unresolved.
Conceptual extension lifecycle: enabling creates a timer and retains its identifier; disabling removes the source and clears the reference before another enable. Hiding the panel alone leaves the timer lifecycle unresolved. Chart : PeopleAreGeek. Data source.
View full-size image

A proposal is not an adopted project-wide rule

Sophie Herold’s July 27 discussion proposes an RFC framework and feedback before applying it to itself. Replies debate decision records, stakeholders and the discussion venue. The thread is evidence of that proposal, not proof that GNOME adopted a final AI policy.

Separately, Javad Rahmatzadeh’s extension reference asks submitters to understand JavaScript and maintain their code. It highlights cleanup, signals, timeouts and process separation. These are concrete review concerns regardless of how the first draft was written.

A small lifecycle example explains the cost

Suppose an extension starts a timer whenever it is enabled. If disabling it only hides the panel, the timer can keep firing. Enabling it again can create another timer. What looked like one working feature now has duplicated callbacks and references to UI that may no longer exist.

Our diagram pairs allocation with cleanup: create a source, retain its identifier, remove it during teardown and clear the reference. The same ownership question applies to signal connections and cancellable asynchronous work. This is an explanatory example, not a tested extension or a universal implementation recipe.

Two different review records

For code, make it possible to answer who owns each resource, when it is released and what happens on repeated enable/disable cycles. For governance, record the decision, the alternatives considered and who accepted the tradeoff. A polished proposal cannot demonstrate runtime cleanup, and a working extension cannot establish project-wide consensus.

That distinction makes both documents more useful. Contributors can act on the existing review guidance while following the RFC discussion for changes to how broader decisions are recorded. Describing the two as one newly adopted anti-AI rule would obscure both their scope and their status.

September 8: distinguish a governance proposal from extension review guidance; remove unsupported claims of adopted policy and link the actual lifecycle responsibilities.