Mailing Lists

Mailing lists are the spine of Apache governance. Every decision that affects the project — design, release, new committer, security disclosure — happens on a mailing list, in an archived thread, with a documented vote when required. This chapter is the operational manual for the Tez lists.

The Tez Lists

Archive: https://lists.apache.org/list.html?dev@tez.apache.org and equivalent for each list. Anything posted is public forever (except private@, which is archived but not public).

Subscribing

# From the address you want subscribed:
echo "" | mail -s "" dev-subscribe@tez.apache.org
# You will get a confirmation request. Reply to it.

For multiple lists, repeat. To unsubscribe, replace subscribe with unsubscribe.

Filtering

issues@tez.apache.org posts dozens of mails per day. Set a Gmail / Outlook / Thunderbird rule to file it into a folder. Same for commits@tez.apache.org if you subscribe.

For dev@, file by subject prefix:

ASF Mailing-List Mores

Lists predate the web at Apache. The conventions are old and load-bearing.

Plain text only

HTML mail is dropped by some clients, breaks quoting, and bloats archives. Apache lists are plain-text. Configure your mail client:

• Gmail web: Settings → General → Default text style → Plain text
• Mutt / mu4e / aerc: already plain
• Outlook: File → Options → Mail → Plain Text

Inline reply, not top-post

The Apache convention is to reply under the relevant quoted text, quoting only the part you're answering. Trim aggressively.

On Tue, May 7, 2024, Foo Bar wrote:
> Should we bump the default for tez.am.resource.memory.mb?

Yes, but conditionally. See the sizing sketch on TEZ-4321.

> And what about the AM heap?

Same patch; -Xmx is computed from -resource.memory.mb in the launch
command. We don't need a separate knob.

-- 
Jane

What top-post would do — your full reply at the top, the original quoted in full below — makes archive threads unreadable. People will gently note this once; do not require a second note.

No attachments

Patches go on JIRA. Logs and stack traces go in a gist or a pastebin and are linked. Long output goes as an attachment to the JIRA, not the email.

A 2 MB attachment forces hundreds of subscribers to download it. A link forces only the interested.

Sign off

A short sign-off — first name, or first + last — is conventional. No corporate signature block, no legal disclaimer, no "Sent from my iPhone."

If you must have a signature, use the standard -- \n separator (dash-dash-space) so mail clients can suppress it.

Subject hygiene

Subject prefixes are filterable. Use them.

Don't prefix replies. The Re: is enough; subscribers' filters key off the embedded [VOTE] already.

Reply-To etiquette

ASF lists are configured to set Reply-To: list. So your reply goes to the list by default. Don't break it by manually rewriting the To:.

If you want to reply privately to the sender (rare — use only for personal/off-topic), explicitly remove the list and address them.

[VOTE] Mechanics

ASF votes are the formal decision mechanism. They use a fixed +1 / 0 / -1 syntax.

Voting tokens

The -1 (a "veto") is a heavy tool. It must be accompanied by a technical justification. A -1 without justification is invalid. Once a valid -1 is cast on a code change, the issue must be resolved (typically by revision) before the change proceeds.

Binding vs non-binding votes

Non-binding votes are welcomed and counted, but only the binding count determines the outcome.

Required minimums

For releases, the ASF rule:

• 72-hour minimum vote duration.
• At least 3 binding +1 votes.
• More +1 than -1 votes.

If those conditions aren't met by close, the vote is extended or fails. See Release Voting for the full mechanics.

For code changes in Tez (RTC project — see JIRA & Code Review):

• Typically 1 binding +1 (a committer) is sufficient to commit, after review.
• A -1 from any committer or PMC member blocks the commit pending resolution.

For new committers / PMC:

• Run on private@.
• Typically a few-day vote window.
• Pass: more +1 than -1; common practice is at least 3 +1.

Lazy consensus

Many decisions don't require a vote. The mechanism is lazy consensus:

"I'm planning to do X. Speaking up if you disagree; otherwise I'll proceed in 72 hours."

Used for things like cutting a branch, scheduling a release-vote window, or applying a trivial fix. The poster picks a reasonable window (24–72 hours). Silence = consent.

Lazy consensus is not for irreversible decisions (release, license change, PMC membership). Those require an explicit vote.

Composing a [VOTE] Email

Template — release vote (the full version is in Release Voting):

Subject: [VOTE] Apache Tez 0.10.4 RC1

Hi all,

I'd like to call a vote on releasing Apache Tez 0.10.4 RC1.

Source release:  https://dist.apache.org/repos/dist/dev/tez/tez-0.10.4-RC1/
Git tag:         release-0.10.4-rc1
Commit hash:     <full sha>
Staging Nexus:   https://repository.apache.org/content/repositories/orgapachetez-NNNN/

KEYS file:       https://downloads.apache.org/tez/KEYS
Signed with key: <your key id and fingerprint>

The vote will be open for 72 hours.

[ ] +1 Release this package
[ ]  0 No opinion
[ ] -1 Do not release because ...

My +1.

Thanks,
<First>

Template — new committer (run on private@):

Subject: [VOTE] New Tez committer: <First Last>

Hi PMC,

I'd like to propose <First Last> as a new committer on Apache Tez.

<First Last> has been contributing since <month year> and has had
<N> patches committed, spanning <areas>. Highlights:

  - TEZ-NNNN: <one line>
  - TEZ-NNNN: <one line>
  - Active reviewer on TEZ-XXX, TEZ-YYY.

They've shown <judgement / quality / breadth>.

Vote open for 72 hours.

[ ] +1
[ ]  0
[ ] -1

My +1.

Thanks,
<First>

Template — closing a vote:

Subject: [VOTE][RESULT] Apache Tez 0.10.4 RC1

Hi all,

The vote on Apache Tez 0.10.4 RC1 has passed with the following tally:

Binding +1: <list of names>
Non-binding +1: <list of names>
0: <names if any>
-1: <names if any, with reasons>

I'll proceed with the release steps.

Thanks to everyone who voted.

<First>

Lazy Consensus Examples

Good lazy-consensus posts:

• "I'm cutting branch branch-0.10.5 from current master tomorrow at 12:00 UTC unless there's objection."
• "Planning to apply TEZ-4321 (one-line log fix, trivial) by end of week unless someone flags it. Patch is .001 on JIRA."
• "Will cancel the 0.10.5 RC1 vote and roll RC2 tomorrow due to the LICENSE finding."

Bad lazy-consensus posts:

• "Going to release 0.10.5 next week." (Requires a [VOTE].)
• "Going to add NAME as committer." (Requires a [VOTE] on private@.)
• "Going to remove the deprecated key X." (User-visible behavior; requires [DISCUSS] → consensus.)

When You're New on the List

The first month of reading a list:

• Read every [VOTE] thread.
• Read every [DISCUSS] thread.
• Skim [jira] [Created] mails.
• Post nothing initially.

After the first month:

• Reply to a user@ question you can answer.
• Post a self-introduction (see Community Interaction).
• Comment on a [DISCUSS] thread once you have substance.

Validation Artifacts

After this chapter:

1. Subscriptions confirmed to dev@, user@, and (if your mail client tolerates the volume) issues@.
2. Mail-client filters configured for the subject prefixes table.
3. A ~/tez-notes/vote-templates.md containing the four templates above.
4. The reflex to inline-reply, not top-post.
5. One archived [VOTE] thread URL bookmarked for reference.

The next chapter — JIRA & Code Review — is the operational view of what code review looks like from the committer side of the table.