Bazel 維護人員指南

回報問題 查看原始碼

本指南旨在說明 Bazel 開放原始碼專案的維護者。

如果您要為 Bazel 做出貢獻,請參閱「貢獻給 Bazel」。

本頁的目標如下:

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

Bazel 的核心貢獻者群組有專門的子團隊,負責管理開放原始碼專案的各面向。分別是:

  • 發布程序:管理 Bazel 的發布程序。
  • 綠色團隊:打造健全的規則和工俱生態系統。
  • 開發人員體驗園藝:鼓勵外部貢獻、查看問題和提取要求,並使開發工作流程更加開放。

版本

持續整合

閱讀 Green 團隊針對 bazelbuild/continuous-integration 存放區中 Bazel 持續整合基礎架構的指南。

問題的生命週期

  1. 使用者選擇其中一個問題範本後建立問題,就會進入未審查的待解決問題所有。
  2. 開發人員體驗 (DevEx) 子團隊旋轉的成員會審查問題。
    1. 如果問題不是錯誤功能要求,DevEx 成員通常會結案,並將使用者重新導向至 StackOverflowbazel-Talk,以便進一步掌握問題內容。
    2. 如果問題屬於社群擁有的其中一個規則存放區 (例如 rules_apple),則 DevEx 成員會將這個問題轉移到正確的存放區。
    3. 如果問題不明確或缺少資訊,DevEx 成員會將問題指派給使用者,要求對方提供更多資訊,然後才繼續。這通常是因為使用者未選擇正確的問題範本 {: .external},或提供不完整的資訊。
  3. 查看問題後,DevEx 成員可決定問題是否需要立即處理。如果是,就會指派「P0」P0優先順序標籤,以及團隊主管清單中的擁有者。
  4. DevEx 成員會指派 untriaged 標籤和一個轉送團隊標籤
  5. DevEx 成員也會根據問題類型指派一個 type: 標籤,例如 type: bugtype: feature request
  6. 針對平台相關問題,DevEx 成員會指派一個 platform: 標籤,例如針對 Mac 相關問題指派 platform:apple
  7. 如果問題的優先度較低,且可以由新的社群貢獻者解決,DevEx 成員會指派 good first issue 標籤。在這個階段,問題會進入未分類的未解決問題集區。

每個 Bazel 子團隊都會將自身標籤下的所有問題分類,最好是每週。子團隊會審查及評估問題,並盡可能提供解決方法。如果您是團隊標籤的擁有者,請參閱這一節 瞭解詳情。

問題解決後可能會關閉。

提取要求的生命週期

  1. 使用者建立提取要求。
  2. 如果您是 Bazel 團隊的成員,並對自己的區域傳送 PR,就必須指派團隊標籤,並找出最佳審查人員。
  3. 否則,在每日分類時,DevEx 成員會指派一個團隊標籤和團隊的技術主管 (TL) 進行轉送。
    1. 技術負責人可選擇指派其他人進行公關審查。
  4. 指派的審查人員會審查 PR,並與作者合作,直到該 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: * 標籤,並改用團隊標籤。

如需完整的標籤清單,請按這裡