本指南旨在說明 Bazel 開放原始碼專案的維護者。
如果您要為 Bazel 做出貢獻,請參閱「貢獻給 Bazel」。
本頁的目標如下:
- 做為專案貢獻程序的維護者可靠資料來源。
- 設定社群貢獻者和專案維護者的期望。
Bazel 的核心貢獻者群組有專門的子團隊,負責管理開放原始碼專案的各面向。分別是:
- 發布程序:管理 Bazel 的發布程序。
- 綠色團隊:打造健全的規則和工俱生態系統。
- 開發人員體驗園藝:鼓勵外部貢獻、查看問題和提取要求,並使開發工作流程更加開放。
版本
持續整合
閱讀 Green 團隊針對 bazelbuild/continuous-integration 存放區中 Bazel 持續整合基礎架構的指南。
問題的生命週期
- 使用者選擇其中一個問題範本後建立問題,就會進入未審查的待解決問題所有。
- 開發人員體驗 (DevEx) 子團隊旋轉的成員會審查問題。
- 如果問題不是錯誤或功能要求,DevEx 成員通常會結案,並將使用者重新導向至 StackOverflow 和 bazel-Talk,以便進一步掌握問題內容。
- 如果問題屬於社群擁有的其中一個規則存放區 (例如 rules_apple),則 DevEx 成員會將這個問題轉移到正確的存放區。
- 如果問題不明確或缺少資訊,DevEx 成員會將問題指派給使用者,要求對方提供更多資訊,然後才繼續。這通常是因為使用者未選擇正確的問題範本 {: .external},或提供不完整的資訊。
- 查看問題後,DevEx 成員可決定問題是否需要立即處理。如果是,就會指派「P0」P0優先順序標籤,以及團隊主管清單中的擁有者。
- DevEx 成員會指派
untriaged
標籤和一個轉送團隊標籤。 - DevEx 成員也會根據問題類型指派一個
type:
標籤,例如type: bug
或type: feature request
。 - 針對平台相關問題,DevEx 成員會指派一個
platform:
標籤,例如針對 Mac 相關問題指派platform:apple
。 - 如果問題的優先度較低,且可以由新的社群貢獻者解決,DevEx 成員會指派
good first issue
標籤。在這個階段,問題會進入未分類的未解決問題集區。
每個 Bazel 子團隊都會將自身標籤下的所有問題分類,最好是每週。子團隊會審查及評估問題,並盡可能提供解決方法。如果您是團隊標籤的擁有者,請參閱這一節 瞭解詳情。
問題解決後可能會關閉。
提取要求的生命週期
- 使用者建立提取要求。
- 如果您是 Bazel 團隊的成員,並對自己的區域傳送 PR,就必須指派團隊標籤,並找出最佳審查人員。
- 否則,在每日分類時,DevEx 成員會指派一個團隊標籤和團隊的技術主管 (TL) 進行轉送。
- 技術負責人可選擇指派其他人進行公關審查。
- 指派的審查人員會審查 PR,並與作者合作,直到該 PR 獲得核准或遭到捨棄為止。
- 如果獲得核准,審查人員會將 PR 的修訂項目匯入 Google 內部版本管控系統,以進行後續測試。由於 Bazel 是 Google 內部使用的建構系統,因此我們必須針對內部測試套件測試所有 PR 修訂版本。因此我們不會直接合併 PR。
- 如果匯入的修訂版本通過所有內部測試,系統就會壓縮修訂版本並匯出回 GitHub。
- 將修訂版本合併至主要執行個體時,GitHub 會自動關閉 PR。
我的團隊擁有某個標籤,該怎麼做?
子團隊需要將自己擁有的標籤中的所有問題進行分類,最好每週執行一次。
問題
- 依團隊標籤和
untriaged
標籤篩選問題清單。 - 查看問題。
- 找出優先順序等級並指派標籤。
- 如果問題為 P0,DevEx 子團隊可能已優先處理這個問題。如有需要,請重新設定優先順序。
- 每個問題只能有一個優先順序標籤。如果問題為 P0 或 P1,我們會假設目前已經積極處理問題。
- 移除
untriaged
標籤。
請注意,您必須位於 bazelbuild 機構中,才能新增或移除標籤。
提取要求
- 依據團隊標籤篩選提取要求清單。
- 查看開啟的提取要求。
- 選用:如果您已獲指派審查,但並非適合該審查,請重新指派適當的審查人員來執行程式碼審查。
- 與提取要求建立者合作完成程式碼審查。
- 核准 PR。
- 確認所有測試都通過。
- 將修補程式匯入內部版本管控系統,並執行內部預先提交。
- 提交內部修補程式。如果修補程式成功提交及匯出,GitHub 將自動關閉 PR。
優先順序
維護人員將使用下列優先順序定義來分類問題。
- P0:造成 Bazel 版本 (排除候選版本) 變得無法使用或嚴重影響 Bazel 專案開發的服務中斷服務。這包括新版本中出現封鎖大量使用者的迴歸,或與破壞性變更政策不相容的破壞性變更。目前沒有可行的解決方法。
- P1:必須在下一個版本中解決重大瑕疵或功能,或是影響許多使用者的嚴重問題 (包括 Bazel 專案的開發),但已有實務解決方法。通常不需要立即採取行動。需求相當高,而且預計在本季的發展藍圖中。
- P2:應處理的瑕疵或功能,但我們目前無法處理。在已發布的 Bazel 版本中,有中型問題對使用者來說不便解決,而且/或可行的解決方法仍然存在。
- P3 - 透過微小影響來修正或強化所需的小錯誤。即使不優先採用 Bazel 藍圖或任何即將發布的版本,但我們鼓勵社群貢獻心力。
- P4 - 優先順序低的瑕疵或功能要求不太可能關閉。如果影響更多使用者,也可以保持開啟狀態,進行潛在的重新優先順序調整。
- 冰箱
- 我們目前還沒有時間處理或審核貢獻內容的問題。我們會關閉這些問題,表示沒有人在處理這些問題,但會持續監控這類問題的有效性,並在影響到足夠人數以及是否有足夠的資源可以處理這些問題時,再予以恢復。如同以往,即使這些問題已關閉,也可以隨時留言或回應。
團隊標籤
team-Android
:Android 團隊相關問題- 聯絡人:ahumesky
team-Bazel
:一般 Bazel 產品/策略問題- 聯絡人:meisterT
team-CLI
:控制台使用者介面- 聯絡人:meisterT
team-Configurability
:設定團隊相關問題。包含:核心建構設定和轉換系統。不包含:新增或現有旗標的變更- 聯絡人:gregestren
team-Core
:Skyframe、Bazel 查詢、BEP、選項剖析、bazelrc- 聯絡人:haxorz
team-Documentation
:說明文件團隊相關問題team-ExternalDeps
:外部依附元件處理、Bzlmod、遠端存放區、WORKSPACE 檔案- 聯絡人:meteorcloudy
team-Loading-API
:建立檔案和巨集處理:label、package()、Visibility、glob- 聯絡人:brandjon
team-Local-Exec
:執行 (本機) 團隊相關問題- 聯絡人:meisterT
team-OSS
:Bazel OSS 團隊的問題:安裝、發布程序、Bazel 封裝、網站、文件基礎架構- 聯絡人:meteorcloudy
team-Performance
:Bazel Performance 團隊的問題- 聯絡人:meisterT
team-Remote-Exec
:執行 (遠端) 團隊相關問題- 聯絡人:coeuvre
team-Rules-API
:用於編寫規則/規格的 API:供應器、執行檔、動作、構件- 聯絡人:comius
team-Rules-CPP
/team-Rules-ObjC
:C++/goal-C 規則相關問題,包括原生 Apple 規則邏輯。- 聯絡人:buildbreaker2021
team-Rules-Java
:Java 規則的問題- 聯絡人:hvadehra
team-Rules-Python
:原生 Python 規則的問題- 聯絡人:rickeylev
team-Rules-Server
:Bazel 內含的伺服器端規則問題- 聯絡人:comius
team-Starlark-Integration
:非 API Bazel + Starlark 整合。包含:Bazel 如何觸發 Starlark 解譯器、Stardoc、內建插入、字元編碼。「不」包括:BUILD 或 .bzl 語言問題。- 聯絡人:brandjon
team-Starlark-Interpreter
:Starlark 解譯器的問題 (java.net.starlark 中的任何內容)。BUILD 和 .bzl API 問題 (代表 Bazel 與 Starlark 的「整合」) 都會在team-Build-Language
中出現。- 聯絡人:brandjon
針對新問題,我們已淘汰 category: *
標籤,並改用團隊標籤。
如需完整的標籤清單,請按這裡。