Bazel 維護人員指南

回報問題 查看原始碼 。 。 。 。 夜間 。 。 。 。 7.3 。 。 7.2 。 。 7.1 。 。 7.0 。 。 6.5 。 。

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

如果您需要解決 Bazel 問題，請參閱將 Bazel。

此頁面的目標是：

  1. 擔任維護人員專案貢獻的可靠資料來源 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作
  2. 規範社群貢獻者與專案的期望 維護人員

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

  • 版本程序：管理 Bazel 的發布程序。
  • 綠色團隊：發展健全的規則與工俱生態系統。
  • 開發人員體驗園地：鼓勵外部人員貢獻評論 設定問題及提取要求，並讓開發工作流程更順利。

版本

持續整合

閱讀 Green 團隊的指南，瞭解 Bazel 的 CI 基礎架構 bazelbuild/continuous-integration Cloud Storage 也提供目錄同步處理功能

問題的生命週期

  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 並與作者合作，直到 核准或捨棄
  5. 核准後，審查人員會將 PR 的修訂版本匯入 Google 的 內部版本管控系統，以便進一步測試由於 Bazel 屬於同一建構項目 系統在 Google 內部使用系統時，需要根據 內部測試套件。因此我們並未直接合併 PR。
  6. 如果匯入的修訂版本通過所有內部測試，系統就會壓縮修訂版本 並將資料匯出回 GitHub
  7. 修訂版本合併至主要執行個體時，GitHub 會自動關閉 PR。

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

子團隊需要將自有標籤中的所有問題分類 建議每週 1 次

問題

  1. 按照團隊標籤和 untriaged 標籤篩選問題清單。
  2. 查看問題。
  3. 找出優先順序等級並指派標籤。
    1. DevEx 子團隊可能已優先處理這個問題 第 0 頁：視需要重新設定優先順序。
    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: * 標籤，並換成團隊 標籤

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