2020-12-02 conda-forge 核心會議
與會者
- Cheng H. Lee (CHL)
- Crystal Soja (CAS)
- Filipe (FF)
- John Kirkham
- Keith Kraus
- Matthew Becker
- Isuru Fernando
- Sylvain Corlay
- Eric Dill
- Markus Gerstel
- Chris Burr
- CJ Wright
- Paul Ivanov
- Connor Martin
- Stephanie Guo
- Marcel Bargull
議程
常設項目
-
在會議中為新成員介紹
-
(CJ) 預算
- 目前的核准?
- 當更新的數字出來時,請螢幕分享並顯示預算。
- 連結在 Keybase 中 (numfocus_spreadsheets.txt)
- (CJ) 我們都已更新,十月份的損益為零
-
公開投票
- Markus 負責 staged-recipes
-
(MRB/ED/SC) 路線圖 / 資金
- 將在下週的特別會議中繼續
- 目標是在每次核心會議花費 15 分鐘,共約 3-4 次會議來討論這個
- 保留最後 15 分鐘用於此。
- https://hackmd.io/0zGSUS71SbOdBsdLtDmGjg
- 筆記將添加到上面的 hackmd 中
- MRB 將整理成一份文件
- 一些資源
- 一些數字
- https://github.com/conda-forge/by-the-numbers/blob/master/conda-forge-timelines.ipynb
- conda-forge 在 2019 年每年新增約 3k 個 feedstock,2020 年也將如此
- 我們儲存的資料量增長似乎正在加速
- 風險評估
- 一些數字
- 今天因為我自己的限制而跳過
- 待辦事項
- 大家看看 pypa 路線圖
- 填寫風險評估試算表:https://github.com/psf/fundable-packaging-improvements/blob/master/FUNDABLES.md
來自上次會議
- (MRB/IF) pybind11 套件
- 問題:https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/849#issuecomment-727207060
- 我們同意一個 pybind11-abi 元套件,它
- 使用 pybind11 內部 abi 進行版本控制
- 對自身進行 run export
- pybind11 將對其版本進行 run_constrained
- 可以由使用者選擇性地添加到 host envs 中,以在需要時強制執行 ABI 相容性
- IF:這具有強制執行一個全域 pybind11 ABI 的副作用
您的新議程項目
-
(Filipe) Kaleido PR 仍在擱置中:https://github.com/conda-forge/staged-recipes/pull/12747
- ED:我們可以先合併,然後再修復嗎?
- FF:我們就這麼做吧!
-
(Filipe) 我們需要一個新的 conda-build 版本來修復 Windows 上的前綴問題,否則我們需要在那裡使用非常舊的版本。
- 影響 pyqt 和 sip
- IF:我們應該回溯移植
- FF:如果很快,那麼就不需要
- CHL:應該在未來兩三週內發布
-
(CJ) NumFOCUS 正在進行法律問答,我們是否有具體問題要問他們?
-
(CJ) Depfinder 稽核結果
- 各種改進已納入基於 depfinder 的依賴性檢查系統。
- 這個 jupyter notebook 顯示了一些結果
- 關於 depfinder 有一些重要的細微之處
- 如果所有 conda run 需求都被發現是必要的或有問題的導入,則 feedstock 是「準確的」(從 depfinder 的角度來看)。有問題的導入是指被遮蔽的導入,因此它們可能不會被運行(在函數內部、try except 後面等)
- 稽核是在原始碼本身上運行的,而不是在產生的
site-packages
上,因此我們本來不會發布的文件(測試、範例等)可能會被納入稽核。 - 稽核對可選文件沒有太多可見性,因此我們假設所有文件(及其相關的導入)都是必要的。這可能會導致 depfinder 認為 conda-forge 未充分指定。
- 如果 feedstock 需要一個會覆蓋其他套件的 pkg,那麼我們可能會遺失需求,因為這些導入在形式上是由覆蓋 pkg 提供的
- 這些稽核可以構成以下工作的基础
- 修復我們遺失必要依賴項和傳遞依賴項的依賴性
- 修復上游需求規格,並確定上游規格在 pkg 需求層級的可靠性
- 協助維護者就依賴項更新做出明智的決策
- 稽核原始碼:https://github.com/regro/cf-scripts/blob/master/conda_forge_tick/audit.py#L39
- 導入地圖:https://github.com/regro/libcfgraph/tree/master/import_maps
-
(MRB) 打包 ray
- 我們有一個可行的配方:https://github.com/conda-forge/staged-recipes/pull/11160
- 我們對此感到滿意嗎?
- KK:將推廣給我認識的關心這個的人
-
(MRB) 非標籤 github actions 使用
- 我們至少有兩個 feedstock 正在 conda-forge org 中使用 github actions 來執行其自訂 CI 腳本
- 我們無法支援每個 feedstock 都這樣做
- 我給他們發了一條訊息:https://github.com/conda-forge/pangeo-notebook-feedstock/issues/49
- 我們需要一個政策。
- 待辦事項
- MRB:提出進行 50% 投票
-
(MRB) artifact-validation 和前綴中的覆蓋
- 請參閱此處:https://github.com/conda-forge/artifact-validation
- 其運作方式如下
- 當套件複製請求發送到 heroku 服務時,它會將 artifact 發送以透過 GHA repo dispatch 事件進行驗證
- 此事件在 github actions 上運行驗證 CI 工作流程 (https://github.com/conda-forge/artifact-validation/actions?query=workflow%3Avalidate-artifact)
- 驗證工作流程下載 artifact,仔細檢查 MD5 總和檢查碼,然後使用一組 glob 過濾器檢查其文件中不允許的路徑
- glob 過濾器列在 yaml 文件中,這些文件指示哪些路徑受到保護,以及哪些套件被允許寫入這些路徑
- 我們結合了手動指定的路徑和產生的路徑
- 手動指定的路徑在此處:https://github.com/conda-forge/artifact-validation/tree/master/validate_yamls
- 產生的路徑在此處:https://github.com/conda-forge/artifact-validation/tree/master/generated_validate_yamls
- 我們使用 libcfgraph 中的文件列表來產生受保護的路徑
- 我們還使用 libcfgraph 和下載持續掃描 artifacts
- 我們還在新增套件時更新過濾器
- 下一步
- 將無效的 artifacts 標記為損壞:https://github.com/conda-forge/artifact-validation/blob/master/scan_data/invalid_packages.yaml
- 從 GHA 驗證工作流程上傳到 anaconda.org,並且不要上傳無效的 artifacts
- 擴展過濾器集
- FF:向 PyPA 發送一些資料
-
(CHL) conda 和 conda-forge 用於 IoT、嵌入式等領域
- Anaconda 很好奇是否有人正在使用、計劃使用或想要在這種環境中使用 conda 及其套件生態系統;如果是,需要做什麼才能(更好)地支援它。
- 答案
- 機器人
- NVIDIA Jetsons 和 RAPIDS 信號處理庫
推遲到下次會議
進行中投票
子團隊更新
Bot
ARM
POWER
CUDA
文件
staged-recipes
網站
安全性+系統
CI 基礎架構
編譯器升級
CFEP 更新
開放 PR
-
cfep-04 X11 和 CDT 政策
- 非活動狀態 - 以某種非活動狀態合併?
- 需要新的擁護者。感謝 pkgw 在這個 pkgw 上的工作!自 2020 年 1 月 10 日起,pkgw 仍有未解決的評論
-
cfep-06 Staged-recipes 審查生命週期
- 非活動狀態 - 以某種非活動狀態合併?
- 來自 @saraedum 的持續評論。@jakirkham,您可以回覆嗎?自 2020 年 1 月 8 日起,@saraedum 仍有未解決的評論
- (MRB) stalebot 已經解決了這裡最糟糕的問題。我認為我們可以永久延遲這個。
-
cfep-10 Feedstock 狀態,未維護
- 非活動狀態 - 以某種非活動狀態合併?
- 需要另一次審查。自 2020 年 1 月 11 日起,pkgw 仍有未解決的更新
-
cfep-12 移除違反來源套件條款的套件
- 自 2020 年 5 月 26 日起停滯
- 關於移動到「損壞」與從 conda-forge 頻道刪除之間的積極辯論
- 進行中投票,於 2020-03-11 結束
- 投票結果如何?
- 我們收到 NumFOCUS 的回覆了嗎?
-
cfep-17 處理 pin 回溯移植和依賴項重建
- Isuru、CJ 和 Matt 之間關於實作細節的停滯辯論
- 2020-07-22 更新:原則上,我們同意在臨時基礎上(即,直到遷移結束)直接在 feedstock 中呈現所需的多餘 pinnings。
討論
檢查先前的行動項目
從上次會議議程複製先前的行動項目。
本次會議
2020-11-24
上次會議
2020-11-18
- (IF/MRB/MV) intel oneAPI
- 待辦事項
- (Nikolay) opencl_rt 的授權
- (Nikolay) intelmpi ABI 與 mpich 的相容性
- (MRB/IF) 弄清楚如何準確地打包 C/C++ 編譯器
- (MRB/IF) 考慮 fortran ABI
- (MRB) 建立 conda-forge 編譯器室(新增人員,包括 keith)
- 待辦事項
- (MB) 要求核心成員轉為「榮譽退休」狀態
- 待辦事項:Eric 設定核心成員的季度檢查,以查看他們是否有興趣保持「活躍」狀態,或者他們是否想轉為榮譽退休
- 移除榮譽退休人員存取各種憑證的權限(api tokens、twitter 密碼等)?這需要修改治理文件。
- 待辦事項:Eric 設定核心成員的季度檢查,以查看他們是否有興趣保持「活躍」狀態,或者他們是否想轉為榮譽退休
2 次會議前
2020-11-11
- 待辦事項:考慮邀請 JOSS 提供關於我們如何最好地撰寫論文的背景資訊
移至 Issue Tracker
2020-11-03
- (MRB) 關於核心成員何時推送到他們未維護的 feedstock 的擬議政策 * [x] (MRB) 放入文件 PR * [ ] (MRB) 在 bot 上建立 PR 以提及該政策
- 待辦事項:檢查 Forrest Watters 的核心權限
- (FF) Outreachy 將花費 6500 美元。
- 下一步:撰寫摘要並投票決定資金支出。
2020-10-28 2020-10-21
- (Marius?) Python 2.7 遷移
- ( ) [ ] 提出提示
- ( ) [ ] 發布公告
- ( ) [ ] 將提示設為 lint
2020-10-07
- 確保將 NVBug 資訊添加到 conda-forge 製作的 cudatoolkit 套件中(如果我們製作一個)
2020-09-30
2020-09-23
- (MRB)
- 執行 libgfortran 名稱變更
- 將目標平台新增到 hashes
- 使用 bot 執行 gfortran 遷移
- 提高 pinnings
2020-09-16
- 與 Jon Mease 安排關於 kaleido staged recipes PR 的通話
- 已於 2020-09-16 發送電子郵件
- (FF) 在 python feedstock 上開啟 python 3.9 的 PR,看看哪些失敗
2020-09-09
- (ED) 使用與 conda-tools 中相同的投票模型更新治理文件(+3 且沒有 -1 即為通過)
- (SC) 編寫 jinja 模板以將機構合作夥伴 yaml 轉換為網站 https://github.com/conda-forge/conda-forge.github.io/blob/2a2d3caaf7d74eb370ac40c679ba337a73d15c8a/src/inst_partners.yaml
- (SC) 記錄創建 OVH 帳戶並獲得存取權限所需執行的操作
2020-08-26 Docker hub
- (JK) 檢查 Azure build workers 以查看它們是否具有 docker hub 限制。
- (JK) 與 dockerhub 合作,看看我們是否可以獲得 OSS 狀態
- 在某個時間點再次檢查。截至 2020-09-23,我們尚未收到回覆
- (MRB) 開始將映像檔推送到 quay (https://github.com/conda-forge/docker-images/pull/152)
OVH
-
(???) 建立網頁以感謝他們(和其他人)
-
如果我們要新增標誌,將需要確保我們有權限使用它。
-
在某個時間點在 twitter 上大聲疾呼。「感謝 OVHCloud 提供 VM」等等。(也許在我們在 windows 上發布 qt 後?)
-
弄清楚如何向使用者傳達重大變更。可能應該立即開啟 issue 以進行進一步討論。Ping @kkraus,加上從這些會議記錄中捕獲的筆記
-
John K. 將更新 git repo 上的 cuda toolkit feedstock,以註明 NVBug 連結到 NVIDIA 內部 issue tracker
-
Jonathan 將更新文件以註明一些非詳盡的套件列表(例如 cuda-toolkit、MKL 等)
-
Jonathan 將審查此 PR
-
(Kale) 安排 conda 工作小組
-
cfep-10 下一步:CJ 呼籲投票徵求意見
-
cfep-06 下一步:要求 staged recipes 團隊擁護此 CFEP 並推動其前進
-
jakirkham 和 CJ-wright 同步將 CUDA 新增到遷移 bot
-
(Eric) 安排 Anaconda <-> conda-forge 在 anaconda.org 上同步需求收集
- 將嘗試在下個月安排此行程。
-
(Anthony) 聯繫 NumFocus 以弄清楚不包括文件中的許可證的法律後果。
-
(Eric) 內部檢查社群飯店和機票的資金水平?
-
(Eric) 弄清楚 conda-forge 的財務狀況以支持他們自己?
-
(jjhelmus) 開啟 CFEP 以了解我們將支援哪些 python 版本
-
(jakirkham) 撰寫一篇關於我們今天討論的 CUDA 內容的部落格文章
-
(jakirkham) 更新關於如何將 CUDA 支援新增到 feedstocks 的文件
-
(jakirkham) 將在 conda-smithy 上開啟一個 issue 以調查 Drone 問題。(ping aarch 團隊)
-
(ED) 關於我們的頁面?FAQ 和每個人是誰的某種組合。FAQ 諸如
- CF <> Anaconda、CF <> NumFocus、CF <> Azure 的 POC 是誰
- 各個子團隊的 POC 是誰?
- 非正式資訊:角色、日常工作、簡歷、所有細節、您來這裡的原因等等。
- 公開還是內部?我真的不在乎哪種方式。有人強烈偏向其中一種嗎?
- 選擇加入公開簡歷
- software carpentry 有大量的講師,並且有 https://carpentries.org/instructors
- 對「又一個需要保持更新的地方」感到擔憂
-
(ED) 記錄使用 conda-forge 的可重現環境策略
-
(UK) 靜態程式庫內容
- 將 linting 提示新增到 builds 以找到它們
- 建議如何打包它們 -> CFEP-18
- 我們應該編寫文件,說明我們不提供支援,這是一個壞主意。 -> CFEP-18