2020-10-21 conda-forge 核心會議

與會者

* Eric D
* Matt B
* Filipe
* Cheng Lee
* Isuru
* Marius
* Crystal
* Marcelo
* Paul I.
* Marcel B.
* Connor M.
* Bill Batey
* Stephanie
* John K.
* Lori B.
* Wolf
* CJ

議程

常設項目

在會議中為新成員介紹
- Bill - Anaconda 新成員。與 Cheng 和 Connor 在發行團隊。
(CJ) 預算
- 目前批准情況？
- 當更新的數字出來時，請螢幕分享並顯示預算。
  - 連結在 Keybase 中 (numfocus_spreadsheets.txt)
(MRB) 公開投票
- Chris Burr 參選核心成員
- 不會再使用 polys，因為有些事情完全出錯了。也許我們稍後會再試一次？

來自先前會議

(MRB) github releases 和 conda-forge-sparta
- 程式碼和資料目前在 regro github org 中
  - 如果您需要存取權限，請告知我 (LMK)
  - 我也很樂意將 repo 移動到 conda-forge org，但由於它們使用了相當多的 github actions，因此可能會減慢重新渲染速度
- 運作方式
  - 所有經過驗證並複製到 anaconda.org/conda-forge 的套件也會透過 github actions 中的 workflow dispatch event 發送到 releases repo
  - github actions CI 工作 (regro/releases)
    - 下載套件
    - 計算其 repodata 資訊
    - 將套件及其 repodata 上傳為 github release
    - 將 repodata 分片推送到另一個包含所有分片的 repo
  - 在持續迴圈中的另一個工作 (regro/repodata 又名 repoworker)
    - 下載分片
    - 找出哪些是新的
    - 將 repodata 修補套用到分片 (如果修補程式已變更，也會重新修補所有內容)
    - 計算 repodata 和 channel data
    - 計算指向套件下載位置的連結索引
    - 將所有這些資料上傳為 github release
    - 啟動 heroku 伺服器以下載新的連結
  - herkou 伺服器 (https://conda-forge-sparta.herokuapp.com/conda-forge-sparta/)
    - 取得針對 anaconda 伺服器的標準 URL 的套件或 repodata 檔案請求
    - 在連結索引中查找該套件的位置
    - 發出 300 以將請求重新導向到實際位置
  - 最後一組 cron jobs 每小時執行一次，以將我們的 repodata 分片與 anaconda.org 同步 (regro/repodata-shards)
    - 此工作捕捉因 CI 工作不良或手動上傳而遺漏的任何 release
      - 將更新分片 repo 並上傳到 github
    - 確保在 ~1-2 小時的時間範圍內最終一致性，以防發生問題
- 從初始 workflow dispatch 到套件可用的整體時間延遲為 5-10 分鐘
  - 如果正在為所有內容重新執行 repodata 修補程式，則時間可能會更長
- 如果我們需要它，這如何才能不依賴 anaconda
  - 用 quetz 取代 cf-staging 和 anaconda.org
  - 限制到這些實例的流量以降低成本
  - 將絕大多數下載請求發送到我們的 (可能已強化的) heroku 伺服器，從而發送到 github
- 我真的不想為了生產環境而維護這個，但如果我們必須這樣做，我們也可以。
- 目前，我們有一個系統可以幫助索引和存檔我們的資料在另一個地點。
(MRB / ED / SC) 路線圖 / 資金？在 gitter 中討論
- (SC) 如果 conda-forge 作為一個專案收到資金，它會做什麼？也許在 conda-forge 網站上發布一些白皮書會有所幫助。如果某公司透過 NumFOCUS 向該專案捐贈 1 萬美元、10 萬美元或 100 萬美元，conda-forge 會做非常不同的事情嗎？
  - 1 萬美元：它是否購買了足夠的託管來做一些有趣的事情？
  - 10 萬美元 - 它帶來了什麼。
  - 更大的金額：conda-forge 甚至可以資助人們直接從事該專案。
  - 我們幾乎可以肯定地找到許多有用的東西，這些東西不會妨礙獲得資金，而無需就路線圖達成共識。（我認為這不會引起爭議，例如哦，我們可以利用一些資金來進行一些不錯的網路開發，以更好地視覺化遷移或其他東西）可能有很多類似性質的事情。
- 如果我們列出一個清單，聖誕老人可能會出現...
- 請參閱上面的 bloomberg 筆記...
- 願望清單和想法：https://hackmd.io/0zGSUS71SbOdBsdLtDmGjg
  - (ED) 我們可以為提交想法的人添加姓名縮寫嗎？如果後續有問題，追蹤會很有用
  - (MRB) 在下一次核心會議中開始針對此議題討論 15 分鐘
(MvN) 關於 cython 的戰術性事項？
- CPython 經常破壞其 apis，迫使 python 生態系統的大部分內容重新 cython 化。
- 我們是否應該修補我們的 cython，以便在設定 CONDA_BUILD 環境變數時，我們始終重新 cythonize 並忽略檔案的 mtime？
(MvN) noarch：python v2
- 隨著我們越來越不相容 py27/35/36，我們是否應該自動將 python 約束新增至所有 noarch: python artifacts，使用 repodata patching？
  - 這個想法是選擇一個 epoch 日期 (例如 2020-10-01)，並讓該日期之後建置的 artifacts 取得 repodata patch，如果它只有 python 約束，則新增 python>=3.6 約束。
- 此外，我們也可以更新 noarch 新增 bot 動作，該動作會從 recipe 中剝離所有包含 py27/34/35 selectors 的行。
  - 這應該可以讓我們移動許多目前僅為了 py27 相容性而依賴某些東西的 feedstocks 到 noarch: python，從而減少 artifacts 的成長率。
- 待辦事項
  - ( ) [ ] 製作提示
  - ( ) [ ] 發布公告
  - ( ) [ ] 將提示變成 lint
(WV) multisheller github.com/wolfv/multisheller

您的新增議程項目

(FF) Outreachy，第二輪
(FF) feedstock 和 staged-recipes 之間的「功能對等」。例如：CFEP-05 沒有考慮在沒有穩定版本來啟動 feedstock 時，在 staged recipes 上發布 dev 版本。https://github.com/conda-forge/cfep/blob/master/cfep-05.md
- 不需要 conda-forge.yml，可以新增 conda config 檔案
- 更廣泛的問題仍然沒有解決，我們無法執行 cos7
- staged recipes 需要一些工作！

延後到下次會議

進行中的投票

子團隊更新

Bot

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 channel 刪除之間的積極辯論
- 進行中的投票，於 2020-03-11 結束
- 投票結果如何？
- 我們有收到 NumFOCUS 的回覆嗎？
cfep-17 處理 pin backports 和 dependency rebuilds
- 關於 Isuru、CJ 和 Matt 之間實作細節的停滯辯論
- 2020-07-22 更新：原則上我們同意在 feedstock 中直接渲染所需的額外 pinnings (即，直到遷移結束)。
cfep-20

討論

檢查先前的行動項目

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

本次會議

2020-10-21

Python 2.7 遷移
- ( ) [ ] 製作提示
- ( ) [ ] 發布公告
- ( ) [ ] 將提示變成 lint

上次會議

2020-10-07

確保將 NVBug 資訊新增到 conda-forge 製作的 cudatoolkit 套件中 (如果我們製作一個)

2 次會議前

2020-09-30

移至 Issue Tracker

2020-09-23

(MRB)
- 執行 libgfortran 名稱變更
- 將目標平台新增至 hashes
- 使用 bot 執行 gfortran 遷移
- bump 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 template 將機構合作夥伴 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

與會者​

議程​

常設項目​

來自先前會議​

您的新增議程項目​

延後到下次會議​

進行中的投票​

子團隊更新​

Bot​

ARM​

POWER​

CUDA​

文件​

staged-recipes​

網站​

安全+系統​

CI 基礎架構​

編譯器升級​

CFEP 更新​

未結 PR​

討論​

檢查先前的行動項目​

本次會議​

上次會議​

2 次會議前​

移至 Issue Tracker​

與會者

議程

常設項目

來自先前會議

您的新增議程項目

延後到下次會議

進行中的投票

子團隊更新

Bot

ARM

POWER

CUDA

文件

staged-recipes

網站

安全+系統

CI 基礎架構

編譯器升級

CFEP 更新

未結 PR

討論

檢查先前的行動項目

本次會議

上次會議

2 次會議前

移至 Issue Tracker