Bazel 維護人員指南

回報問題 查看原始碼 夜間 7.4 ，直接在 Google Cloud 控制台實際操作。 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 成員會 將問題重新指派給使用者，要求對方提供更多資訊 繼續。這通常是使用者未選擇正確的問題範本 {: .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. 負責人可以選擇指派其他人檢視 PR。
  4. 指派的審查人員會審查 PR，並與作者合作，直到 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 - 低優先順序的缺失或功能要求，不太可能關閉。可同時保持開啟 如果有更多使用者受到調整，可以重新安排優先次序。
  • ice-box
    • 我們目前沒有時間處理的問題，也沒有時間接受貢獻。我們會關閉這些問題，表示沒有人正在處理這些問題，但會持續監控這些問題的有效性，如果有足夠的人受到影響，且我們恰好有資源處理這些問題，就會重新啟用這些問題。如往，即使問題已關閉，您仍可對其發表意見或新增回應。

團隊標籤

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

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