Bazel 維護人員指南

回報問題 查看來源

這份指南提供 Bazel 開放原始碼專案的維護人員指南。

如果您想要協助 Bazel，請改為參閱對 Bazel 做出貢獻一節。

此頁面的目標是：

  1. 做為專案貢獻程序的維護者可靠資料來源。
  2. 設定社群貢獻者與專案維護人員的期望。

Bazel 的核心協作者有專門的子團隊來管理開放原始碼專案的層面。包括：

  • 版本程序：管理 Bazel 的發布程序。
  • 綠色團隊：發展健全的規則與工俱生態系統。
  • Developer Experience Gardeners：鼓勵外部貢獻、審查問題和提取要求，並讓開發工作流程更開放。

發行內容

持續整合

請參閱 Green 團隊有關 Bazel 持續整合基礎架構的指南，瞭解 bazelbuild/Continuous-integration 存放區。

問題的生命週期

  1. 使用者選擇其中一個問題範本來建立問題，該範本就會進入未審查的待解決問題集區。
  2. 開發人員體驗 (DevEx) 子團隊輪替的成員會審查問題。
    1. 如果問題不是錯誤或功能要求，DevEx 成員通常會關閉問題，並將使用者重新導向至 StackOverflow 和 bazel-discuss，以取得更多問題資訊。
    2. 如果問題屬於社群擁有的其中一個規則存放區 (例如 rules_apple)，DevEx 成員會將這個問題轉移到正確的存放區。
    3. 如果問題很模糊或缺少資訊，DevEx 成員會將問題指派給使用者，要求對方提供更多資訊，然後再繼續。當使用者未選擇正確的問題範本 {: .external} 或提供不完整的資訊時，通常就會發生這種情形。
  3. DevEx 成員在查看問題後，決定是否需要立即處理問題。如果會的話，他們將會指派「P0」P0標籤和主管名單中的一位擁有者。
  4. DevEx 成員會指派 untriaged 標籤和一個團隊標籤進行轉送。
  5. DevEx 成員也會根據問題類型指派一個 type: 標籤，例如 type: bug 或 type: feature request。
  6. 對於平台相關問題，DevEx 成員會指派一個 platform: 標籤，例如用於 Mac 特定問題的 platform:apple。
  7. 如果問題的優先順序低，且可由新的社群貢獻者處理，DevEx 成員會指派 good first issue 標籤。在這個階段，問題已進入未分類的待解決問題集區。

每個 Bazel 子團隊都會依自身的標籤分類所有問題，建議每週處理一次。子團隊會審查並評估問題，並視情況提供解決方法。如果您是團隊標籤的擁有者，請參閱這個章節 瞭解詳情。

問題解決後，您可以結案。

提取要求的生命週期

  1. 使用者建立提取要求。
  2. 如果您屬於 Bazel 團隊成員，並傳送 PR 給自己的區域，請自行指派團隊標籤及尋找最佳審查者。
  3. 否則，在每日分類中，DevEx 成員會指派一個團隊標籤和團隊的技術主管 (TL) 進行轉送。
    1. 負責人可以選擇指派其他人檢視 PR。
  4. 指派的審查人員會審查 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 機構中，才能新增或移除標籤。

提取要求

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

優先順序

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

  • P0 - 導致 Bazel 版本 (排除候選項目) 無法使用的主要功能故障，或是服務中斷，嚴重影響 Bazel 專案的開發作業。這包括在封鎖大量使用者的新版本中導入迴歸，或是不相容的破壞性變更不符合「破壞性變更」政策。目前沒有實際可行的解決方法。
  • P1：應在下一版中解決的重大瑕疵或功能問題，或是影響許多使用者 (包括 Bazel 專案開發) 的重大問題，但實際存在解決方法。通常不需要立即採取行動。由於需求量龐大，且預計於本季的藍圖中規劃。
  • P2：需要處理或需要解決的功能問題，但我們目前尚未處理。在已發布的 Bazel 版本中，解決當下問題，對使用者來說不便於日後版本處理及/或提供簡便的解決方法。
  • P3：所需的小錯誤修正或增強，而影響不大。請放心，在 Bazel 藍圖或任何即將發布的版本中都沒有優先採用，但我們仍建議社群貢獻內容。
  • P4：優先順序較低的瑕疵或功能要求不太可能關閉。如果更多使用者受到影響，您也可以保持開放，以便重新排定優先順序。
  • 冰箱
    • 我們目前沒有時間處理或接受捐款的問題我們會關閉這些問題，以指出沒有任何人正在工作，但會繼續監控這些問題的有效性，並在有足夠人受到影響，且剛好有資源可以處理時，即可改善它們。和往常一樣，即使關閉這些問題 也歡迎你留言或回應這些問題

團隊標籤

對於新問題，我們淘汰了 category: * 標籤，並換成團隊標籤。

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