發布管理員

「發布管理員」是一個總括術語，涵蓋了一組 Kubernetes 貢獻者，他們負責維護發布分支，並使用 SIG Release 提供的工具來建立發布版本。

以下說明每個角色的職責。

• 聯絡方式
  • 安全禁運政策
• 手冊
• 發布管理員
  • 成為發布管理員
• 發布管理員助理
  • 成為發布管理員助理
• SIG Release 領導
  • 主席
  • 技術領導

聯絡方式

安全禁運政策

關於發布的一些資訊受到禁運限制，我們已定義關於如何設定這些禁運的政策。請參閱安全禁運政策以取得更多資訊。

手冊

注意：修補程式發布團隊和分支管理員手冊將在稍後取消重複。

• 修補程式發布團隊
• 分支管理員

發布管理員

注意： 文件可能會提及修補程式發布團隊和分支管理角色。這兩個角色已合併為發布管理員角色。

發布管理員和發布管理員助理的最低要求是

• 熟悉基本的 Unix 命令，並且能夠偵錯 Shell 腳本。
• 熟悉透過 git 和相關的 git 命令列調用進行分支原始碼工作流程。
• Google Cloud (Cloud Build 和 Cloud Storage) 的一般知識。
• 願意尋求協助並清楚地溝通。
• Kubernetes 社群成員資格

發布管理員負責

• 協調和切割 Kubernetes 發布版本
  • 修補程式發布 (x.y.z，其中 z > 0)
  • 次要版本發布 (x.y.z，其中 z = 0)
  • 預先發布版本 (alpha、beta 和候選發布版本)
  • 在每個發布週期中與發布團隊合作
  • 設定修補程式發布的排程和節奏
• 維護發布分支
  • 審查 Cherry Pick
  • 確保發布分支保持健全，並且不會合併非預期的修補程式
• 指導發布管理員助理群組
• 積極開發功能並維護 k/release 中的程式碼
• 透過積極參與 Buddy 計劃來支援發布管理員助理和貢獻者
  • 每月與助理進行簽到並委派任務、授權他們切割發布版本和指導
  • 能夠支援助理招募新的貢獻者，例如回答問題和建議他們可以做的適當工作

此團隊有時與安全回應委員會密切合作，因此應遵守安全發布流程中規定的準則。

GitHub 存取控制：@kubernetes/release-managers

GitHub 提及：@kubernetes/release-engineering

• Adolfo García Veytia (@puerco)
• Cici Huang (@cici37)
• Carlos Panato (@cpanato)
• Jeremy Rickard (@jeremyrickard)
• Marko Mudrinić (@xmudrii)
• Nabarun Pal (@palnabarun)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)
• Verónica López (@verolop)

成為發布管理員

若要成為發布管理員，必須先擔任發布管理員助理。助理透過在多個週期中積極參與發布工作而晉升為發布管理員，並且

• 展現領導意願
• 與發布管理員在修補程式上進行標籤團隊合作，最終獨立切割發布版本
  • 由於發布具有限制功能，我們也會考慮對映像檔升級和其他核心發布工程任務的重大貢獻
• 質疑助理的工作方式、提出改進建議、收集意見回饋並推動變革
• 可靠且反應迅速
• 傾向於需要發布管理員層級存取權限和權限才能完成的進階工作

發布管理員助理

發布管理員助理是發布管理員的學徒，以前稱為發布管理員見習生。他們負責

• 修補程式發布工作、Cherry Pick 審查
• 貢獻 k/release：更新依賴項並習慣原始碼庫
• 貢獻文件：維護手冊，確保發布流程已記錄
• 在發布管理員的協助下：在發布週期期間與發布團隊合作，並切割 Kubernetes 發布版本
• 尋求機會協助優先順序排序和溝通
  • 發送關於修補程式發布的預先公告和更新
  • 更新日曆，協助更新發布週期時間軸中的發布日期和里程碑
• 透過 Buddy 計劃，招募新的貢獻者並與他們配對執行任務

GitHub 提及：@kubernetes/release-engineering

• Arnaud Meukam (@ameukam)
• Jim Angel (@jimangel)
• Joseph Sandoval (@jrsapi)
• Xander Grzywinski(@salaxander)

成為發布管理員助理

貢獻者可以透過展現以下特質成為助理

• 持續參與，包括 6-12 個月的積極發布工程相關工作
• 在發布週期期間，擔任發布團隊技術領導角色的經驗
  • 此經驗為理解 SIG Release 的整體運作方式提供穩固的基礎 — 包括我們對技術技能、溝通/回應能力和可靠性的期望
• 處理 k/release 項目，以改善我們與 Testgrid 的互動、清理程式庫等。
  • 這些努力需要與發布管理員和助理互動和配對

SIG Release 領導

SIG Release 主席和技術領導負責

• SIG Release 的治理
• 領導發布管理員和助理的知識交流會議
• 領導力與優先順序排序指導

在此明確提及他們，是因為他們是每個角色的各種溝通管道和權限群組 (GitHub 團隊、GCP 存取權) 的所有者。因此，他們是享有高度特權的社群成員，並且可以知悉一些私密溝通，這些溝通有時可能與 Kubernetes 安全性揭露有關。

GitHub 團隊：@kubernetes/sig-release-leads

主席

• Jeremy Rickard (@jeremyrickard)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)

技術領導

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Verónica López (@verolop)

過去的分支管理員可以在 kubernetes/sig-release 儲存庫的 releases 目錄中的 release-x.y/release_team.md 中找到。

範例：1.15 發布團隊