Apache Governance & Process — Questions with Complete Answers

These are the questions a PMC member, a release manager, or an interviewer at an ASF-adjacent company will expect you to answer precisely. Vague answers signal you have never actually shipped through the process.

Table of Contents

Roles and trust

Q: What is the difference between a contributor, a committer, and a PMC member?

A contributor is anyone who submits patches, files issues, improves docs, or answers questions — no formal status. A committer has earned write access to the repository by PMC vote; commits still go through review norms, but the committer can merge. A PMC (Project Management Committee) member holds binding governance authority: their votes are binding on releases, they elect new committers and PMC members, and the PMC collectively is accountable to the ASF Board for the project's health and legal compliance. Every PMC member is a committer; the reverse is not true.

Q: What does "Apache is a meritocracy built on trust" mean operationally?

Status is granted retroactively for sustained behavior, never requested. The PMC is not evaluating one patch; it is answering "would we give this person the keys and sleep well?" That is why review tone, follow-through on stuck patches, willingness to maintain what you ship, and how you take criticism all weigh as much as code quality. The trust audit in Phase 01 maps exactly this.

Q: What is the ASF's stance on corporate influence?

Individuals, not companies, hold merit. A committer's status is personal and survives changing employers. Projects must not be controlled by a single vendor ("independence" is reviewed by the Board); decisions happen on public mailing lists — "if it didn't happen on the list, it didn't happen."

Releases and voting

Q: Walk me through an Apache release from code freeze to announcement.

  1. Release manager (RM) cuts a release branch; blockers tracked in JIRA against the version.
  2. RM produces a release candidate: source tarball (the official artifact — binaries are convenience), signed with the RM's GPG key, checksums published, staged (commonly to a Nexus staging repo and dist.apache.org dev area).
  3. RM starts a [VOTE] thread on the dev list, linking artifacts, signatures, and tag.
  4. Voting runs a minimum of 72 hours. Release votes require at least 3 binding +1 votes (PMC members) and more binding +1 than -1. A -1 on a release is not a veto — it is a vote, and the release can still pass, though a serious -1 usually sinks an RC socially.
  5. Anyone can vote; only PMC votes are binding. Voters are expected to state what they checked (signatures, checksums, build from source, license files, no unexpected binaries).
  6. On pass: RM publishes to downloads.apache.org/mirrors, releases the staging repo to Maven Central, tags, updates the website, and sends [ANNOUNCE].

Q: What must you verify before casting +1 on a release candidate?

Signature verifies against a key in the project's KEYS file; checksums match; the source tarball builds and passes tests from a clean environment; LICENSE/NOTICE are present and accurate for bundled dependencies; no compiled binaries or category-X licensed code in the source release; the git tag matches the tarball contents. Phase 04's signing lab makes you do each step by hand.

Q: Why is the source tarball the official release rather than the git tag or binaries?

Legally, the ASF releases source code under the Apache License; the foundation's infrastructure, signing, and voting process protect exactly that artifact. Binaries are unofficial conveniences built from it. This is also why license hygiene of the tarball is a release-blocking concern while a bad binary is merely embarrassing.

Vetoes and consensus

Q: When does -1 mean veto, and what makes a veto valid?

On code modifications (commits), -1 from a committer/PMC member is a veto and must be respected — but only if accompanied by a technical justification. An unjustified veto is invalid. Vetoes cannot be overridden by majority; they are resolved by addressing the objection or convincing the vetoer. On procedural matters (releases, electing people), -1 is just a vote — majority/3×+1 rules apply instead.

Q: What is lazy consensus and when do you rely on it?

Stating intent ("I plan to merge this in 72 hours unless objections") and proceeding if nobody objects. It keeps low-controversy work moving without requiring explicit +1s from busy people. You do not rely on it for API changes, behavior changes with compatibility impact, or anything previously contested — those need explicit review.

Q: A committer merges your patch, then another committer posts a justified -1. What happens?

The veto stands even post-merge: the change is reverted or fixed forward to address the objection. The right response from you is to engage the technical objection on its merits, not to argue process. How you behave in exactly this moment is committer-candidacy signal.

Compatibility policy

Q: How do mature Apache projects define compatibility promises?

Via annotated audience and stability levels — Hadoop's @InterfaceAudience.{Public,LimitedPrivate,Private} × @InterfaceStability.{Stable,Evolving,Unstable}, Spark's @DeveloperApi/@Experimental/@Since. Public+Stable APIs cannot break within a major line; semver-like rules govern what minor and patch releases may change. Tools like japicmp (Phase 04 lab) and explicit MiMa rules (Spark) enforce this in CI.

Q: Why is removing a deprecated method still a big deal?

Deprecation is a signal, not a license. Removal is a major-version event, requires the deprecation to have shipped in at least one minor release with a documented migration path, and the cost lands on every downstream user simultaneously. Phase 11's migration analyzer lab encodes the urgency model: deprecated-since × usage-count × replacement-availability.

Becoming a committer

Q: What does a PMC actually look at when voting on a new committer?

A months-long public record: merged patches across more than one area; review comments on other people's patches that show judgment; mailing-list answers that are correct and patient; JIRA hygiene (good reports, reproductions, follow-through); no abandoned messes. Quantity matters less than the question "does this person act like an owner already?"

Q: How do you pick a first issue in a large Apache project without wasting reviewer time?

Start with issues labeled starter/newbie; reproduce the bug first and say so on the JIRA; read the relevant module's recent commits to learn local conventions; keep the first patch small and test-covered; state explicitly what you tested. The fastest trust-builder is a patch the reviewer can merge without a second round.

Q: Your patch has been ignored for three weeks. What do you do?

One polite ping on the JIRA/PR mentioning the reviewer(s) who touched the file recently; if silent, raise it in the dev list's review-request thread conventions for the project. Never cross-post repeatedly or DM-pressure. Meanwhile, review someone else's patch — reciprocity is the unwritten queue discipline of OSS review.

References