Bazel 維護人員指南

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

本指南適用於 Bazel 開放原始碼專案的維護者。

如要為 Bazel 做出貢獻，請改為閱讀「為 Bazel 做出貢獻」。

本頁面的目標如下：

  1. 做為維護人員的可靠資料來源，瞭解專案的貢獻程序。
  2. 在社群貢獻者和專案維護者之間建立期望。

Bazel 的核心貢獻者群組設有專屬子團隊，負責管理開放原始碼專案的各個層面。包括：

  • 發布程序：管理 Bazel 的發布程序。
  • 綠色團隊：建立健全的規則和工具生態系統。
  • 開發人員體驗園丁：鼓勵外部貢獻、審查問題和提取要求，並讓我們的開發工作流程更加開放。

版本

持續整合

請參閱 bazelbuild/continuous-integration 存放區，瞭解 Green 團隊的 Bazel CI 基礎架構指南。

問題的生命週期

  1. 使用者使用問題範本建立問題，問題會進入未審查的待處理問題集區。
  2. 開發人員體驗 (DevEx) 子團隊輪值成員會審查問題。
    1. 如果問題不是錯誤或功能要求，DevEx 成員通常會關閉問題，並將使用者重新導向 StackOverflow 和 bazel-discuss，以提高問題的曝光度。
    2. 如果問題屬於社群擁有的其中一個規則存放區 (例如 rules_apple)，DevEx 成員會將這個問題轉移至正確的存放區。
    3. 如果問題含糊不清或缺少資訊，DevEx 成員會將問題指派回給使用者，要求提供更多資訊，然後再繼續處理。通常是因為使用者未遵循問題範本。
  3. DevEx 成員審查問題後，會決定是否需要立即處理。如果確實如此，他們會指派 P0 優先順序標籤，並從團隊領導人清單中指派擁有者。
  4. DevEx 成員會指派 untriaged 標籤和一個 團隊標籤，以利轉送。
  5. DevEx 成員也會根據問題類型，指派一個 type: 標籤，例如 type: bug 或 type: feature request。
  6. 如果是平台專屬問題，DevEx 成員會指派一個 platform: 標籤，例如 platform:apple 代表 Mac 專屬問題。此時，問題會進入未分類的待處理問題集區。

每個 Bazel 子團隊都會優先處理所屬標籤下的所有問題，最好每週一次。子團隊會審查及評估問題，並盡可能提供解決方案。如果你是團隊標籤的擁有者，請參閱這個部分 瞭解詳情。

問題解決後，即可關閉案件。

提取要求的生命週期

  1. 使用者建立提取要求。
  2. 如果您是 Bazel 團隊成員，並針對自己的領域傳送 PR，請負責指派團隊標籤並尋找最佳審查員。
  3. 否則，在每日分類期間，DevEx 成員會指派一個團隊標籤和團隊的技術主管 (TL) 以進行轉送。
    1. TL 可視需要指派其他人審查 PR。
  4. 指派的審查員會審查 PR，並與作者合作，直到 PR 獲得核准或遭捨棄為止。
  5. 如果獲得核准，審查人員會將 PR 的提交內容匯入 Google 的內部版本控管系統，以進行進一步測試。由於 Bazel 是 Google 內部使用的建構系統，我們需要針對內部測試套件測試所有 PR 提交。因此我們不會直接合併 PR。
  6. 如果匯入的提交通過所有內部測試，系統會將提交壓縮並匯出回 GitHub。
  7. 修訂版本合併至主要分支時，GitHub 會自動關閉 PR。

我的團隊擁有唱片公司，該怎麼辦？

子團隊需要對所擁有的標籤中的所有問題進行分類，最好每週一次。

問題

  1. 依團隊標籤和 untriaged 標籤篩選問題清單。
  2. 查看問題。
  3. 找出優先順序並指派標籤。
    1. 如果問題屬於 P0，DevEx 子團隊可能已優先處理。視需要重新設定優先順序。
    2. 每個問題都只能有一個優先順序標籤。如果問題為 P0 或 P1，我們假設目前正在積極處理。
  4. 移除「untriaged」標籤。

請注意，您必須位於 bazelbuild organization 中，才能新增或移除標籤。

提取要求

  1. 依團隊標籤篩選提取要求清單。
  2. 查看未完成的提取要求。
    1. 選用：如果系統指派您進行審查，但您不適合這項工作，請重新指派合適的審查人員進行程式碼審查。
  3. 與提取要求建立者合作，完成程式碼審查。
  4. 核准 PR。
  5. 確認所有測試都已通過。
  6. 將修補程式匯入內部版本控管系統，並執行內部預先提交作業。
  7. 提交內部修補程式。如果修補程式提交及匯出成功，GitHub 會自動關閉 PR。

優先順序

維護人員會根據下列優先順序定義，對問題進行分類。

  • P0 - 主要功能損壞，導致 Bazel 版本 (不含候選版本) 無法使用，或服務中斷，嚴重影響 Bazel 專案的開發作業。包括新版本中導入的迴歸，導致大量使用者無法使用，或是不相容的重大變更不符合重大變更政策。目前沒有實用的解決方法。
  • P1 - 重大缺陷或功能，應在下一個版本中解決；或影響許多使用者 (包括 Bazel 專案的開發) 的嚴重問題，但有實際可行的解決方法。通常不需要立即採取行動。需求量高，且已納入本季的發展藍圖。
  • P2 - 應解決的缺陷或功能，但我們目前未處理。已發布的 Bazel 版本有中等程度的即時問題，對使用者造成不便，但可透過日後發布的版本解決，或是有簡單的解決方法。
  • P3 - 建議修正的小錯誤或影響不大的改善項目。不會優先納入 Bazel 藍圖或任何即將發布的版本，但我們鼓勵社群貢獻。
  • P4 - 低優先順序的缺陷或功能要求，不太可能解決。如果更多使用者受到影響，也可以保持開啟狀態，以便重新調整優先順序。
  • ice-box
    • 我們目前沒有時間處理這些問題，也無法接受貢獻內容。我們會關閉這些問題，表示沒有人正在處理，但會持續監控問題的有效性，如果受影響的人數夠多，且我們有資源處理，就會重新開啟問題。如常，即使問題已關閉，您仍可隨時留言或新增回應。

團隊標籤

對於新問題，我們已淘汰 category: * 標籤，改用團隊標籤。

如要查看完整標籤清單，請按這裡。