這份指南提供 Bazel 開放原始碼專案的維護人員指南。
如果您想要協助 Bazel,請改為參閱對 Bazel 做出貢獻一節。
此頁面的目標是:
- 做為專案貢獻程序的維護者可靠資料來源。
- 設定社群貢獻者與專案維護人員的期望。
Bazel 的核心協作者有專門的子團隊來管理開放原始碼專案的層面。包括:
- 版本程序:管理 Bazel 的發布程序。
- 綠色團隊:發展健全的規則與工俱生態系統。
- Developer Experience Gardeners:鼓勵外部貢獻、審查問題和提取要求,並讓開發工作流程更開放。
發行內容
持續整合
請參閱 Green 團隊有關 Bazel 持續整合基礎架構的指南,瞭解 bazelbuild/Continuous-integration 存放區。
問題的生命週期
- 使用者使用問題範本建立問題後,就會進入未審查的待解決問題集區。
- 開發人員體驗 (DevEx) 子團隊輪替的成員會審查問題。
- 如果問題不是錯誤或功能要求,DevEx 成員通常會關閉問題,並將使用者重新導向至 StackOverflow 和 bazel-discuss,以取得更多問題資訊。
- 如果問題屬於社群擁有的其中一個規則存放區 (例如 rules_apple),DevEx 成員會將這個問題轉移到正確的存放區。
- 如果問題很模糊或缺少資訊,DevEx 成員會將問題指派給使用者,要求對方提供更多資訊,然後再繼續。這通常是當使用者未遵循問題範本時。
- DevEx 成員在查看問題後,決定是否需要立即處理問題。如果會的話,他們將會指派「P0」P0標籤和主管名單中的一位擁有者。
- DevEx 成員會指派
untriaged
標籤和一個團隊標籤進行轉送。 - DevEx 成員也會根據問題類型指派一個
type:
標籤,例如type: bug
或type: feature request
。 - 對於平台相關問題,DevEx 成員會指派一個
platform:
標籤,例如用於 Mac 特定問題的platform:apple
。在這個階段,問題已進入未分類的待解決問題集區。
每個 Bazel 子團隊都會依自身的標籤分類所有問題,建議每週處理一次。子團隊會審查並評估問題,並視情況提供解決方法。如果您是團隊標籤的擁有者,請參閱這個章節 瞭解詳情。
問題解決後,您可以結案。
提取要求的生命週期
- 使用者建立提取要求。
- 如果您屬於 Bazel 團隊成員,並傳送 PR 給自己的區域,請自行指派團隊標籤及尋找最佳審查者。
- 否則,在每日分類中,DevEx 成員會指派一個團隊標籤和團隊的技術主管 (TL) 進行轉送。
- 負責人可以選擇指派其他人檢視 PR。
- 指派的審查人員會審查 PR 並與作者合作,直到其核准或捨棄。
- 如果獲得核准,審查人員會將 PR 的修訂版本匯入 Google 內部版本管控系統,以進行進一步測試。由於 Bazel 與 Google 內部使用的建構系統相同,因此我們必須針對內部測試套件測試所有 PR 修訂版本。因此我們並未直接合併 PR。
- 如果匯入的修訂版本通過所有內部測試,修訂版本會壓縮並匯出回 GitHub。
- 修訂版本合併至主要執行個體時,GitHub 會自動關閉 PR。
我的團隊擁有標籤,該怎麼辦?
子團隊需要將「自身擁有的標籤」中的所有問題分類,建議每週一次。
問題
- 按照團隊標籤和
untriaged
標籤篩選問題清單。 - 查看問題。
- 找出優先順序等級並指派標籤。
- 如為 P0,DevEx 子團隊可能已優先處理這項問題。視需要重新設定優先順序。
- 每個問題都必須有一個優先順序標籤。如果問題是 P0 或 P1,我們會假定正在積極解決。
- 移除
untriaged
標籤。
請注意,您必須位於 bazelbuild 機構中,才能新增或移除標籤。
提取要求
- 按照團隊標籤篩選提取要求清單,
- 查看待處理的提取要求。
- 選用:如果您獲派審查,但不適合審查,請重新指派適當的審查人員來執行程式碼審查。
- 請與提取要求建立者合作,完成程式碼審查。
- 請核准 PR。
- 確保通過所有測試。
- 將修補程式匯入內部版本管控系統,然後執行內部預先提交。
- 提交內部修補程式。如果修補程式成功提交及匯出,GitHub 會自動關閉 PR。
優先順序
維護人員會使用下列優先順序定義將問題分類。
- P0 - 導致 Bazel 版本 (排除候選項目) 無法使用的主要功能故障,或是服務中斷,嚴重影響 Bazel 專案的開發作業。這包括在封鎖大量使用者的新版本中導入迴歸,或是不相容的破壞性變更不符合「破壞性變更」政策。目前沒有實際可行的解決方法。
- P1:應在下一版中解決的重大瑕疵或功能問題,或是影響許多使用者 (包括 Bazel 專案開發) 的重大問題,但實際存在解決方法。通常不需要立即採取行動。由於需求量龐大,且預計於本季的藍圖中規劃。
- P2:需要處理或需要解決的功能問題,但我們目前尚未處理。在已發布的 Bazel 版本中,解決當下問題,對使用者來說不便於日後版本處理及/或提供簡便的解決方法。
- P3:所需的小錯誤修正或增強,而影響不大。請放心,在 Bazel 藍圖或任何即將發布的版本中都沒有優先採用,但我們仍建議社群貢獻內容。
- P4:優先順序較低的瑕疵或功能要求不太可能關閉。如果更多使用者受到影響,您也可以保持開放,以便重新排定優先順序。
- 冰箱
- 我們目前沒有時間處理或接受捐款的問題我們會關閉這些問題,以指出沒有任何人正在工作,但會繼續監控這些問題的有效性,並在有足夠人受到影響,且剛好有資源可以處理時,即可改善它們。和往常一樣,即使關閉這些問題 也歡迎你留言或回應這些問題
團隊標籤
team-Android
:Android 團隊相關問題- 聯絡人:ahumesky
team-Bazel
:一般 Bazel 產品/策略問題- 聯絡人:sventiffe
team-Build-Language
:有關 BUILD、.bzl API 和 Stardoc 的問題。- 聯絡人:brandjon
team-Configurability
:設定團隊相關問題- 聯絡人:gregestren
team-Core
:核心團隊相關問題- 聯絡人:haxorz
team-Documentation
:說明文件團隊的問題- 聯絡人:communikit
team-ExternalDeps
:外部依附元件處理、Bzlmod、遠端存放區、WORKSPACE 檔案- 聯絡人:meteorcloudy
team-Local-Exec
:執行 (本地) 團隊的問題- 聯絡人:meisterT
team-OSS
:Bazel OSS 團隊的問題:安裝、發布程序、Bazel 封裝、網站、文件基礎架構- 聯絡人:meteorcloudy
team-Performance
:Bazel Performance 團隊的問題- 聯絡人:meisterT
team-Remote-Exec
:執行 (遠端) 團隊的問題- 聯絡人:coeuvre
team-Rules-CPP
:C++ 規則問題,包括原生 Apple 規則邏輯- 聯絡人:oquenchil
team-Rules-Java
:Java 規則相關問題- 聯絡人:comius
team-Rules-Python
:原生 Python 規則的問題- 聯絡人:comius
team-Rules-Server
:Bazel 包含的伺服器端規則相關問題- 聯絡人:comius
team-Starlark-integration
:非 API Bazel + Starlark 整合。包括:Bazel 如何觸發 Starlark 解譯器、Stardoc、內建插入、字元編碼。「不」包含:BUILD 或 .bzl 語言問題。- 聯絡人:brandjon
team-Starlark-interpreter
:Starlark 解譯器的問題 (java.net.starlark 中的任何內容)。BUILD 和 .bzl API 問題 (這指的是 Bazel 與 Starlark 的「整合」) 出現在team-Build-Language
中。- 聯絡人:brandjon
對於新問題,我們淘汰了 category: *
標籤,並換成團隊標籤。
如需完整的標籤清單,請參閱這裡。