Bazel 維護人員指南

回報問題 查看原始碼 Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

本指南適用於 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 團隊的成員，並且要針對自己的領域傳送提交要求，則必須負責指派團隊標籤，並找出最合適的審查者。
  3. 否則，在每日的初步評估期間，DevEx 成員會指派一個團隊標籤和團隊技術主管 (TL) 來進行分派。
    1. TL 可以選擇指派其他人審查 PR。
  4. 指派的審查人員會審查 PR，並與作者合作，直到 PR 獲得核准或撤銷為止。
  5. 經過核准後，審查人員會imports提交的 PR 至 Google 的內部版本控制系統，以便進行後續測試。由於 Bazel 是 Google 內部使用的建構系統，因此我們需要針對內部測試套件測試所有提交的修訂版本。這就是我們不會直接合併 PR 的原因。
  6. 如果匯入的提交內容通過所有內部測試，系統會合併該提交內容，並將其匯出至 GitHub。
  7. 當提交合併至主分支時，GitHub 會自動關閉 PR。

我的團隊擁有標籤。該怎麼辦？

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

問題

  1. 依團隊標籤和 untriaged 標籤篩選問題清單。
  2. 查看問題。
  3. 指定優先順序等級並指派標籤。
    1. 如果是 P0 問題，DevEx 子團隊可能已將其列為優先處理。視需要重新設定優先順序。
    2. 每個問題都必須具備一個優先順序標籤。如果問題是 P0 或 P1，我們會假設問題正在積極處理中。
  4. 移除 untriaged 標籤。

請注意，您必須屬於 bazelbuild 組織，才能新增或移除標籤。

提取要求

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

優先順序

維護人員會使用下列優先順序定義來分類問題。

  • P0 - 重大故障功能，導致 Bazel 版本 (不含候選版本) 無法使用，或導致服務中斷，嚴重影響 Bazel 專案的開發作業。這包括新版本中引進的回歸，導致大量使用者遭到封鎖，或是不相容的重大變更，違反「重大變更」政策。目前沒有實際的解決方法。
  • P1 - 重大缺陷或功能，應在下一個版本中解決，或影響許多使用者 (包括 Bazel 專案的開發) 的嚴重問題，但有實際的解決方法。通常不需要立即採取行動。需求量高，且已納入本季的發展藍圖。
  • P2 - 應解決的瑕疵或功能，但我們目前未著手處理。已發布的 Bazel 版本中存在中度即時問題，對使用者造成不便，需要在日後的版本中解決，且/或有簡單的解決方法。
  • P3 - 建議修正小型錯誤或改善小型功能，但影響不大。並未列為 Bazel 路線圖或任何即將推出的版本的優先項目，但我們鼓勵社群貢獻內容。
  • P4 - 低優先順序的缺失或功能要求，不太可能關閉。如果有更多使用者受到影響，也可以將這項問題保留，以便重新設定優先順序。
  • ice-box
    • 我們目前沒有時間處理的問題，也沒有時間接受貢獻。我們會關閉這些問題，表示沒有人正在處理這些問題，但會持續監控這些問題的有效性，如果有足夠的人受到影響，且我們恰好有資源處理這些問題，就會重新啟用這些問題。如往，即使問題已關閉，您仍可對其發表意見或新增回應。

團隊標籤

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

如需標籤的完整清單，請參閱這篇文章。