Bazel 維護人員指南

每日版本 · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

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

本頁面的目標如下：

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

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

  • 發布程序：管理 Bazel 的發布程序。
  • 綠色團隊：監控 Bazel CI 健康狀態，並回報中斷情形。
  • 開發人員體驗園丁：鼓勵外部貢獻、審查問題和提取要求，並讓我們的開發工作流程更加開放。

版本

持續整合

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

問題的生命週期

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

每個 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 中，才能新增或移除標籤。

提取要求

外部貢獻者主要透過 PR 為 Bazel 增添價值。身為開放原始碼專案，請務必確保 PR 獲得及時且有效率的審查和處理。

  • 分類

    定期查看標有 awaiting-review 標籤和團隊標籤的 PR。您可以透過輪值或定期會診會議完成這項工作。 我們預計會在 7 個工作天內對每個 PR 做出初步回應。

  • 回應

    • 如果 PR 沒問題，請核准並套用awaiting-PR-merge 標籤。gTech 團隊會將 PR 匯入為 CL。
    • 否則，請提供意見並將 awaiting-review 標籤替換為 awaiting-user-response 標籤。如果 PR 作者回覆，DevEx 子團隊會定期更新標籤。
    • 如果 PR 包含重大變更，請考慮要求設計文件，或在問題中進行事前討論。

  • 停用

    由於資源有限，請務必關閉不符合 Bazel 標準，或我們無法審查或維護的 PR。

    • 如果 PR 與 Bazel 的目標不一致，請關閉 PR 並附上說明。
    • 如果 PR 過大且複雜，請關閉 PR，並要求將其分解成較小的部分。
    • 如果 PR 程式碼品質不符合我們的標準，請關閉 PR 並附上說明。
    • 如果程式碼日後的維護成本過高，請關閉並附上說明。
    • 如果 PR 長時間等待使用者回覆，且貢獻者未回覆，系統會在 30 天後自動將 PR 標示為過時，並在 30 天後關閉。

    關閉 PR 時，請禮貌地說明原因。

優先順序

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

  • P0 - 主要功能損壞，導致 Bazel 版本 (不含候選版本) 無法使用，或服務中斷，嚴重影響 Bazel 專案的開發作業。包括新版本中導入的迴歸，導致大量使用者無法使用，或是不相容的重大變更不符合重大變更政策。目前沒有實用的解決方法。
  • P1 - 重大缺陷或功能，應在下一個版本中解決，或是影響許多使用者 (包括 Bazel 專案的開發) 的嚴重問題，但有實際可行的解決方法。通常不需要立即採取行動。需求量高，且已納入本季發展藍圖。
  • P2 - 應解決的缺陷或功能，但我們目前未處理。已發布的 Bazel 版本中存在中等程度的問題，對使用者造成不便，需要日後發布的版本解決，且/或有簡單的解決方法。
  • P3 - 建議修正的小錯誤或影響不大的改善項目。不會優先納入 Bazel 藍圖或任何即將發布的版本，但我們鼓勵社群貢獻。
  • P4 - 低優先級的缺陷或功能要求，不太可能獲得解決。如果更多使用者受到影響，也可以保持開啟狀態，以便重新設定優先順序。

團隊標籤

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

如需完整標籤清單，請參閱這裡。