跳到主要內容

2020-07-22 conda-forge 核心會議

出席者​

  • Filipe Fernandes
  • Jonathan Helmus
  • Keith Kraus
  • Eric Dill
  • Wolf Vollprecht
  • Marius van Niekerk
  • Matthew Becker
  • Anthony Scopatz
  • CJ Wright
  • Michael Sarahan
  • Cheng Lee
  • Marcell Bargull
  • Isuru Fernando
  • Ray Douglass
  • Marcelo Duarte Trevisani
  • John Kirkham
  • Uwe Korn
  • Sylvain Corlay

議程​

常設項目​

您的新議程項目​

上週未完成的事項​

  • (CL) msys2 套件

    • Anaconda 決定「defaults」頻道的更新計畫
    • 目前不需要立即採取行動

  • (CJ) 重建遷移自動合併預設值

    • 目前自動合併是（組織範圍？）開啟或關閉，但如果可以讓使用者選擇僅針對重建而非版本更新啟用自動合併，那就太好了
    • 這些自動合併可能比版本自動合併更安全，因為依賴項不會更改，而且如果套件損壞，建置更有可能失敗。
    • https://github.com/regro/cf-scripts/pull/1063
    • 整體回應是正面的，我們需要記錄/宣布此變更

  • (CJ) s390x 支援

  • 對於未維護的 feedstock，我們應該怎麼做？

    • 允許使用套件的人員挺身而出維護
    • 應該積極地封存 feedstock
      • 並移除維護者
    • 宣傳未維護的 feedstock（在文件中？）
    • 在 feedstock 儲存庫依賴已封存的內容時發出通知？
    • 待辦事項：在移除使用者後清理團隊

  • (FF) 新的 conda-build 版本，修復了 Windows 前綴問題

  • (MRB) 固定 epoch 草案 CFEP

    • 在此處查看草案：https://hackmd.io/N1hoJGJBSqGTFd83pxCyYA
    • 想法是宣告一些固定檔案作為固定 epoch
    • 然後我們使用 epoch 的固定和最新的固定來渲染配方
    • 討論維護者的負擔
      • 選擇加入與選擇退出模型
    • 討論我們想要支援多少個
      • 目前的建議 (Uwe) 是最多 2 個固定 + 最新
      • 每 6 個月到一年左右標記固定 epoch，這會創建約每年的棄用週期
    • 當我們移動 feedstock 時，機器人將需要發出 PR，以將 feedstock 更新到下一個固定 epoch
    • 為多個 boost 版本建置的替代方案
      • 使 boost 成為矩陣
        • 1.70 (再次) 和 1.72
        • 至少保留 [一段時間] 的固定 boost 版本？
      • 我們是否應該對 ICU 執行類似操作？
        • Uwe 似乎表示否

  • (ED) 新成員和貢獻者的歡迎包？ -- 延遲

  • (KK) 移除 conda-build 中 pre-link 腳本的棄用/警告

    • 警告目前會吞噬來自我們 (NVIDIA) 測試的消息
    • 根據 jakirkham 的說法，目前在 conda forge 套件中使用
    • 如果能在實際安裝套件之前，允許具有專有許可證的套件顯示一些消息，那就太好了
      • NVIDIA 法務部門更希望 CUDA 相關套件能這樣做，並希望為運送編譯器、標頭和其他 EULA 保護的位元鋪路

現有投票​

子團隊更新​

機器人​

ARM​

POWER​

CUDA​

文件​

staged-recipes​

網站​

安全+系統​

  • 仍然需要完成 CFEP-13（在最新的 smithy 發布後，現在可以繼續進行）

CI 基礎架構​

編譯器升級​

CFEP 更新​

開啟的 PR​

  • cfep-04 X11 和 CDT 政策

    • 非活動 - 以某種非活動狀態合併？
    • 需要新的擁護者。感謝 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 日起停滯
    • 關於移動到「broken」與從 conda-forge 頻道刪除的積極辯論
    • 現有投票，於 2020-03-11 結束
    • 投票結果如何？
    • 我們有收到 NumFOCUS 的回覆嗎？

  • cfep-17 處理 pin backports 和依賴項重建

    • Isuru、CJ 和 Matt 之間關於實施細節的辯論停滯
    • 2020-07-22 更新：原則上我們同意在臨時基礎上（即，直到遷移結束）直接在 feedstock 中渲染所需的多餘固定。

討論​

檢查先前的行動項目​

從上次會議議程複製先前的行動項目。

本次會議​

  • 找出如何向使用者傳達重大變更。可能應該立即開啟 issue 以進行進一步討論。Ping @kkraus，並從這些會議記錄中擷取更多筆記
  • (Eric) 待辦事項：在 conda_forge.yaml 中將 strict 作為一個選項，並預設開啟它。在 conda-smithy 中開啟 issue

上次會議​

2 次會議前​

  • Eric 將在我們的文件中新增一個頁面，說明如何在商業關係中與 conda-forge 及其關聯機構互動。
  • Eric 將從 Keith 取得 NVBug 連結，並將其封存到 conda-forge google drive 中。
  • John K. 將更新 git 儲存庫上的 cuda toolkit feedstock，以註記 NVBug 連結到 NVIDIA 內部的 issue 追蹤器
  • Jonathan 將更新文件，以註記一些非詳盡的套件列表（例如 cuda-toolkit、MKL 等）
  • Jonathan 將審查此 PR

3 次會議前​

移動到 Issue 追蹤器​

  • (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 是誰？
    • 非正式資訊：角色、日常工作、簡歷、所有細節、您為何在此等等。
    • 公開或內部？我真的不在乎。有人強烈認為其中一種方式嗎？
    • 選擇加入公開簡歷
    • software carpentry 有大量講師，並且有 https://carpentries.org/instructors
    • 對「另一個保持事物更新的地方」的一些擔憂
  • (CJ) 組建財務子團隊
  • (ED) 記錄使用 conda-forge 的可重現環境策略
  • (UK) 靜態函式庫內容
    • 新增 linting 提示到建置中以找到它們
    • 建議如何封裝它們 -> CFEP-18
    • 我們應該編寫文件說明我們不提供支援，這是一個壞主意。 -> CFEP-18