Bazel 維護人員指南

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

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

如果您想為 Bazel 做出貢獻，請改為參閱「為 Bazel 做出貢獻」。

此頁面的目標是：

  1. 擔任維護人員專案貢獻的可靠資料來源 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作
  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. 負責人可以選擇指派其他人檢視 PR。
  4. 指派的審核人員會審核 PR 並與作者合作，直到 核准或捨棄
  5. 核准後，審查人員會將 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 - 低優先順序的缺失或功能要求，不太可能關閉。可同時保持開啟 如果有更多使用者受到調整，可以重新安排優先次序。
  • 冰箱
    • 我們目前沒有時間處理的問題，也沒有時間接受貢獻。我們會關閉這些問題，表示沒有人正在處理這些問題，但會持續監控這些問題的有效性，如果有足夠的人受到影響，且我們恰好有資源處理這些問題，就會重新啟用這些問題。如往，即使問題已關閉，您仍可對其發表意見或新增回應。

團隊標籤

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

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