2020-09-16 conda-forge 核心會議
出席者
- CJ Wright
- Geoffrey Garret
- Filipe Fernandes
- Uwe Korn
- Keith Kraus
- John Kirkham
- Wolf Vollprecht
- Cheng Lee
- Sylvain Corlay
- Anthony Scopatz
- Matt Becker
- Lori Burns
- Eric Dill
- Michael Sarahan
- Isuru Fernando
- Crystal Soja
- Ray Douglass
議程
常設項目
-
在會議中為新成員介紹
-
(CJ) 預算
- 目前的核准?
- 本月第一次會議,螢幕分享並展示預算?
- 連結在 Keybase 中 (numfocus_spreadsheets.txt)
您的新議程項目
-
(UK) Kaleido PR
- https://github.com/conda-forge/staged-recipes/pull/12093
- 反對意見
- 需要檢查依賴關係,並確保它們與 CF 的其餘部分相容
- 應該在 CF 中建置所有非 Chromium 的部分
- 如果找不到 Chromium,則動態取得
- 需要所有靜態連結套件的許可證
- 具有 libstdc++ 符號的共享庫可能會有問題,請使用 'nm … | grep " T "' 檢查
- (Eric) 待辦事項:與 Jon Mease 安排通話
- scopatz, wolf, marcel
- Uwe 在 issue 上評論
- (Isuru) 他們在 wheel 中供應商化了很多函式庫
-
(CJ) 在 extras 中新增資訊,以說明套件作為匯入名稱提供的內容(對於 python 套件)。這將有助於未來的檢查工作。
-
(MB) Python 3.9 rc2(最終發行候選版?)應該在這幾天發布
- 有人看過了嗎?需要準備什麼?
- 最終版本約在一個月後發布
- (Crystal) Anaconda 尚未處理
- (CJ) 當 3.8 出現時,我們根本沒有準備。我們大約有 3-4 週的準備時間才能產生 3.9 套件
- (Filipe) https://github.com/conda-forge/python-feedstock/issues/270
- 待辦事項:首先應該做最簡單的事情:開啟 PR 並查看哪些失敗。
- 重新基於修補程式,如果修補程式不適用,則開啟一個 issue 說明。
- 半相關:我們如何將我們的修補程式放入 CPython 程式碼庫?
-
(MRB) @ggarrett13 有興趣協助 vs2019 過渡
- 我們需要做什麼才能完成這項工作?
- (Isuru) 這將是全域性的還是僅適用於少數 feedstock?
- 如果是全域性的,那將會有點問題。您可以將使用 2017 和 2019 建置的程式庫連結在一起,但您需要 2019 才能進行連結。這將要求在本地建置 conda 套件的人員更新到 vs2019。Uwe 正在交叉編譯,但我們只有 vs2017。
- 哪些 feedstock 需要更新?只有 vc 那個
- 新的通用執行階段,新增了新的 DLL
- 不在 windows 10 上
- 可以從 windows update 下載
- 建立新的執行階段套件
- jjhelmus 在 gitter 上發布了關於檔案名稱的註記
- 嘗試使用 paul 的 PR 來處理 2019 年的 vc
- 為 2017 年執行該 PR,並在 vc_dev 頻道上嘗試
- 然後為 2019 年執行
- 追蹤版本號碼的來源
來自上次會議
-
(ED) 關於 Isuru 的電腦,我們需要討論什麼嗎?
- 目前打算嘗試 OVH 雲端路線。
- 我們已核准這項方案最多 12 個月。
- 待辦事項:請注意,未來的支出提案應包含 TTL
-
(MRB) GCC 9.3.0 遷移
- 我想確保我了解要做的事情清單
- 據我所知,我們已經建置了所有編譯器
- 需要在 gfortran 堆疊的機器人中進行直接遷移
- 我們是否要變更 linux 上的 libgfortran 程式庫,讓程式庫具有 SO 版本?
- 我遺漏了什麼嗎?
-
(MRB) github 使用者 @jan-janssen 希望在此處的「關聯專案」區段中列出我們 https://pyiron.org/collaborators/
- NumFOCUS 商標指南是:「只要清楚表明使用標記的人並非專案本身或未經專案認可(未經特定許可),則允許大多數用途」
- 他們說最終取決於我們
- 我們是否同意這位使用者顯示我們的標誌並稱我們為「關聯專案」?
- 熱烈贊成!
- 此 PR: https://github.com/pyiron/pyiron.github.io/pull/77
-
(MRB) github docker 映像檔
- 據 AFAICT 稱,除非我們允許 conda-forge 中的任何人建立映像檔並推送它們,否則我們無法在 github 上託管公開 docker 映像檔
- 來自文件的引述 (https://docs.github.com/en/packages/managing-container-images-with-github-container-registry/configuring-access-control-and-visibility-for-container-images#configuring-visibility-of-container-images-for-an-organization)
- 「對於組織映像檔容器,組織管理員必須先啟用公開套件,您才能將可見性設定為公開。如需更多資訊,請參閱「為您的組織啟用 GitHub Container Registry」。」
- (IF) - 從文件中看來,我們無法控制他們新增套件,但我們可以控制誰可以存取現有套件。
- 我嘗試推送映像檔,但無法將其設為公開。
- 因此我們需要一個獨立的組織
- 我提議
conda-forge-docker
進行中的投票
子團隊更新
機器人
ARM
POWER
CUDA
文件
staged-recipes
網站
安全+系統
CI 基礎設施
編譯器升級
CFEP 更新
未完成的 PR
-
cfep-04 X11 和 CDT 政策
- 非作用中 - 合併為具有某些非作用中狀態?
- 需要新的倡導者。感謝 pkgw 在此方面的工作!有來自 pkgw 且未解決的評論,自 2020 年 1 月 10 日起
-
cfep-06 Staged-recipes 審查生命週期
- 非作用中 - 合併為具有某些非作用中狀態?
- 來自 @saraedum 的持續評論。@jakirkham,您可以回覆嗎?有來自 @saraedum 且未解決的評論,自 2020 年 1 月 8 日起
- (MRB) stalebot 已經解決了這裡最嚴重的問題。我認為我們可以永久延後這個問題。
-
cfep-10 Feedstock 狀態,未維護
- 非作用中 - 合併為具有某些非作用中狀態?
- 需要另一次審查。有來自 pkgw 且未解決的更新,截至 2020 年 1 月 11 日
-
cfep-12 移除違反來源套件條款的套件
- 自 2020 年 5 月 26 日起停滯
- 關於移至「損壞」與從 conda-forge 頻道刪除的積極辯論
- 進行中的投票,於 2020-03-11 結束
- 投票結果如何?
- 我們有收到 NumFOCUS 的回覆嗎?
-
cfep-17 處理 pin backport 和依賴項重建
- Isuru、CJ 和 Matt 之間關於實作細節的停滯辯論
- 2020-07-22 更新:原則上,我們同意在 feedstock 中直接呈現所需的額外 pinning(即,直到遷移結束)。
討論
檢查先前的行動項目
從上次會議議程複製先前的行動項目。
本次會議
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 帳戶和取得存取權限所需執行的操作
2 次會議前
移至 Issue Tracker
2020-08-26 Docker hub
- (JK) 檢查 Azure 建置工作站,查看它們是否具有 docker hub 限制。可能是 Azure 和 docker hub
- (JK) 檢查 Azure 建置工作站,查看它們是否具有 docker hub 限制
- (JK) 與 dockerhub 合作,查看我們是否可以獲得 OSS 狀態
- (MRB) 開始將映像檔推送至 quay (https://github.com/conda-forge/docker-images/pull/152)
OVH
-
(???) 建置網頁以感謝他們(和其他人)
-
如果我們要新增標誌,將需要確保我們有權使用它。
-
在 Twitter 上公開表揚。「感謝 OVHCloud 提供 VM」等等。(也許在我們使用它發布 windows 上的 qt 之後?)
-
找出如何向使用者溝通重大變更。可能應該立即開啟一個 issue 以進行進一步討論。Ping @kkraus,加上從這些會議記錄中擷取更上方的註記
-
John K. 將更新 git 儲存庫上的 cuda toolkit feedstock,以註記 NVBug 連結到 NVIDIA 內部 issue 追蹤器
-
Jonathan 將更新文件,以註記一些非詳盡的套件清單(例如 cuda-toolkit、MKL 等)
-
Jonathan 將審查此 PR
-
(Kale) 安排 conda 工作小組會議
-
cfep-10 後續步驟:CJ 呼籲投票以徵求意見
-
cfep-06 後續步驟:要求 staged recipes 團隊倡導此 CFEP 並推動其前進
-
jakirkham & CJ-wright 同步處理將 CUDA 新增至遷移機器人
-
(Eric) 安排 Anaconda <-> conda-forge 同步處理 anaconda.org 需求收集
- 將嘗試在下個月安排此會議。
-
(Anthony) 聯繫 NumFocus 以找出不包含檔案中的許可證的法律後果。
-
(Eric) 內部檢查社群旅館和機票的資助水準?
-
(Eric) 找出 conda-forge 的財務狀況以支持自身?
-
(jjhelmus) 開啟 CFEP,了解我們將支援哪些 python 版本
-
(jakirkham) 撰寫一篇關於我們今天討論的 CUDA 內容的部落格文章
-
(jakirkham) 更新文件,說明如何將 CUDA 支援新增至 feedstock
-
(jakirkham) 將在 conda-smithy 上開啟一個 issue,以調查 Drone 問題。(ping aarch 團隊)
-
(ED) 我們是誰頁面?FAQ 和每個人是誰的某種組合。FAQ 內容例如
- CF <> Anaconda、CF <> NumFocus、CF <> Azure 的 POC 是誰
- 各個子團隊的 POC 是誰?
- 非正式資訊:角色、日常工作、簡歷、所有詳細資訊、您為何在此處等等。
- 公開還是內部?我真的不在意哪種方式。有人強烈傾向於其中一種方式嗎?
- 選擇加入公開簡歷
- 軟體木工坊有大量講師,網址為 https://carpentries.org/instructors
- 對於「又一個需要保持最新狀態的地方」的一些擔憂
-
(ED) 記錄使用 conda-forge 的可重現環境策略
-
(UK) 靜態程式庫內容
- 將 linting 提示新增至建置以找到它們
- 建議如何封裝它們 -> CFEP-18
- 我們應該編寫文件,說明我們不提供支援,並且這是一個壞主意。 -> CFEP-18