Release & PMC Reality

This section takes you inside the committer and PMC view of Apache Tez. The Contributor Mindset section answered "how do I behave so my work gets accepted?" This section answers the opposite, asymmetric question: what is the work being done by the people who accept your patch, cut the releases, and govern the project?

It is written for two audiences:

1. Contributors who want to understand what a committer is reading when they review your patch, why a release vote takes days, and what a PMC member actually does between commits.
2. New committers and PMC members — on Tez or any ASF project — who need the operational playbook nobody hands them.

The chapters are deliberately not aspirational. They are the mechanics: what email to send, what file to sign, what the [VOTE] thread looks like, and where the LICENSE/NOTICE and category-X dependency rules are bright lines.

Why This Matters to You Before You Are a Committer

It is tempting to skip a "release and PMC" section as something for later. Don't. On a maintenance-phase project with a handful of active committers (see the mindset index for the honest activity numbers), release mechanics are one of the highest-leverage, most visible ways a contributor builds a reputation — long before any committership offer.

Two concrete openings:

• Release-blocking bugs are premium contributions. When a release candidate is up for vote, the PMC needs the RC tested — on real workloads, on the JDKs and Hadoop versions people actually run. A contributor who downloads release-0.10.5-rc0, builds it, runs it against a real DAG, and reports a reproducible blocker (or a clean +1 (non-binding) with the details of what they tested) is doing exactly the work the PMC is short-handed on. That is not busywork; a blocker you find prevents a bad release from shipping to every downstream user.
• RC testing is a reputation builder. Your non-binding vote does not count toward the tally, but it is seen. A thoughtful "I tested RC0 on JDK 21 + Hadoop 3.3.6 with a 200-vertex DAG, checksums and signature verified, all green — +1 (non-binding)" on a [VOTE] thread is the kind of reliable, low-drama participation that gets you noticed by the two or three people who decide who becomes a committer. It shows you understand the process, respect it, and can be trusted with more.

In short: you do not need commit access to add value to a release. You need to understand the pipeline — which is what this section teaches.

The Apache Release Pipeline in One Diagram

Every ASF release, Tez included, runs the same shape. The artifact being voted on is the signed source tarball; binaries are a convenience.

 A committer volunteers / is nominated as Release Manager (RM)
        │  [Release Plan: lazy majority of active committers, per the bylaws]
        ▼
 RM cuts a release branch and tags a candidate:  release-0.10.5-rc0
        │
        ▼
 RM builds source tarball, signs it with their GPG key,
 generates SHA-512 checksums, stages to dist.apache.org
        │
        ▼
 RM sends [VOTE] Apache Tez 0.10.5 RC0 to dev@tez.apache.org
        │  vote open ≥ 3 days (excluding weekends)
        ▼
 Community tests the RC:  verify signature + checksum, build from source,
 run apache-rat, exercise real DAGs → replies +1 / 0 / -1 (with reasons)
        │
        ├── blocker found (-1) ──►  RM fixes, cuts rc1, re-votes
        │
        ▼
 Passes: ≥ 3 binding +1 (active PMC members), more +1 than -1
        │  [Product Release: lazy majority of active PMC members]
        ▼
 RM promotes:  moves the artifact to the release area,
 pushes the final tag  rel/release-0.10.5,  updates the website
        │
        ▼
 [ANNOUNCE] on dev@ and announce@apache.org

You can see the tag half of this pipeline in the repo right now:

cd ~/tez-src
git tag | grep 0.10          # release-0.10.5-rc0 ... and the final rel/release-0.10.5

The release-X.Y.Z-rcN tags are the candidates that went to a vote; the rel/release-X.Y.Z tags (protected against deletion and force-push by the ruleset in .asf.yaml) are the ones that passed. The current active line is 0.10.x — that is the branch releases are cut from today.

The Governance Facts Behind the Pipeline

Two approval thresholds from the Tez bylaws (docs/src/site/markdown/by-laws.md) govern the diagram above, and they matter because they explain the who:

"Lazy majority" here means at least 3 binding +1 votes and more +1 than -1. The critical consequence for a small project: only active PMC members cast binding votes on a release, so a release literally cannot ship unless three of them show up and vote. That is why release cadence on a maintenance-phase project is slow, and why an RM's most tedious job is rounding up binding votes. Your non-binding +1 does not solve that — but a blocker you find can save the RM from having to do the whole cycle twice.

Reading Order

Chapters 1–3 and 6–7 are useful to contributors right now. Chapters 4–5 are PMC-facing but worth reading earlier — understanding why a committer behaves the way they do at release time (guarding LICENSE/NOTICE, insisting on a clean apache-rat:check, blocking on a category-X dependency) will save you a stalled PR.

How This Section Differs From the Mindset Section

The Contributor Mindset section is first person: reading the code, recovering design from JIRA, writing a good patch, behaving well on dev@. It is what you do. This section is second person, inverted: it is what the committer reviewing you, the release manager shipping you, and the PMC governing the project do. It is the other side of the table.

You don't need to be a committer to read this material. You need to internalise it before you become one, so the offer — which on this project could genuinely come to a reliable contributor, given how few active committers there are — doesn't catch you off guard.

How This Section Pairs With Level 9 and the Capstone

• Level 9 puts you on the compatibility and wire-format surfaces — exactly the changes a release manager scrutinizes hardest, because a broken wire format ships to every downstream user in a release. Read Licensing and Release Voting alongside Level 9 so you understand why those changes get extra review.
• The Capstone is where you take a real change all the way to a merged patch. Its final steps assume you can read a [VOTE] thread, verify an RC, and understand what "this is release-blocking" means. This section is the reference for those steps.

What This Section Is Not

• Not a substitute for the ASF release distribution policy.
• Not a substitute for ASF legal guidance on licensing.
• Not a substitute for the Tez committer's onboarding email from the PMC.

It is a faithful, project-specific summary of what those documents and that onboarding contain, written so a contributor can build accurate expectations and a new committer can move fast without surprises.

Prerequisites

Before this section is fully useful:

• You have read the Contributor Mindset section.
• You have a JIRA account and are subscribed to dev@tez.apache.org.
• You have a local clone of Tez at ~/tez-src, and have skimmed the bylaws at docs/src/site/markdown/by-laws.md.

If you are a new Tez committer, additionally:

• You have received your ASF ID (<id>@apache.org).
• You have generated a GPG key and had it signed into the Apache web of trust (covered in Release Voting).
• You are subscribed to private@tez.apache.org.

You Have Absorbed This Section When…

1. You can compose a [VOTE] thread for an RC without consulting a template.
2. You can verify a release candidate — signature, SHA-512 checksum, apache-rat:check, build from source — and cast a properly qualified +1 (non-binding).
3. You can explain why a release needs 3 binding +1 votes from active PMC members, and why that makes cadence slow on a small project.
4. You can read a LICENSE/NOTICE change in a patch and predict whether it blocks a release.
5. You can identify the category-A / category-B / category-X status of a dependency you want to add.
6. You can name the current release line (0.10.x) and read the RC-vs-final tag convention in git tag.

The next chapter — Mailing Lists — covers the operational mechanics of the ASF list system that this entire section relies on.