conda-forge 核心會議 2025-01-22
在「Your __new__() agenda items」標題下新增議程項目
出席者
| 姓名 | 縮寫 | GitHub ID | 隸屬關係 |
|---|---|---|---|
| Wolf Vollprecht | WV | wolfv | prefix.dev |
| Klaus Zimmermann | KZ | zklaus | Quansight |
| Uwe Korn | UK | xhochy | QuantCo |
| Jaime Rodríguez-Guerra | JRG | jaimergp | Quansight |
| Matthew R. Becker | MRB | beckermr | cf |
| Marius van Niekerk | MvN | mariusvniekerk | cf |
總共 6 人
常設項目
- [ ]
來自之前會議的項目
- [ ]
進行中的投票
- [ ]
您的 new() 議程項目
-
(JRG) 從 Azure Pipelines 遷移到 Github Actions 以使用 osx-arm64 和 linux-aarch64 runner，以及其他好處。
- Azure 似乎處於功能凍結狀態（這個 issue 在四月被鎖定，這個問題沒有得到回覆）或非常緩慢地推出新功能。自 GHA 開始支援此架構以來已超過一年，自它們普遍可用以來也將近一年。
- 在 Azure 藍圖中，關於 osx-arm64 有一個注意事項，適用於 2025 年第二季。「正在研究定價解決方案」。所以不是免費的？但沒有提到 Linux ARM。
- Travis 不夠可靠，無法為我們提供 linux-aarch64 runner，而 Circle CI 在新倉庫註冊方面遇到問題。
- 如果可能，我建議將我們的 conda-forge 池從一個服務轉移到另一個服務。該池必須與正常的 GHA 池分開，以避免 DoS 攻擊我們的基礎設施（rerender、lint 等等都高度依賴於每個 feedstock 上運行的 GHA 工作流程）。應該聯絡誰？
- 有任何回饋嗎？這是否可行還是個糟糕的主意？潛在的阻礙？
- 行動項目
- Jaime 在 Zulip 線上討論串中起草電子郵件內容。提及潛在的變更，以及新 runner 類型和證明、存取控制、更好的生態系統等等的動機。
- Wolf 尋找 Codespaces 聯絡人
- 有人與 Steve / GH 支援團隊有良好關係的人發送電子郵件？
-
(IF) ABI3 狀態
- CEP 通過 https://github.com/conda/ceps/blob/main/cep-0020.md
- rattler-build 現在有一個實作。需要找出一些錯誤
- conda-build 實作：https://github.com/conda/conda-build/pull/5456 (CL) 可能會在下一個 conda-build 版本中發布 (JRG) 回答關於
defaults打包python-abi3套件的問題，或調整文件
-
(WV) 預設在 staged recipes 上使用 recipe v1
-
(WV) NumFOCUS SDG 用於使用 sigstore 的套件證明
- WV: 這是我正在使用的一個測試倉庫，用於進行一些測試：https://github.com/wolfv/sigstore-test/actions/runs/12909555992
- WV: 你可以在這裡找到一個證明：https://github.com/wolfv/sigstore-test/attestations/4571450
- WV: 你可以在 sigstore.dev 上搜尋 sha hash 以找到已簽署的產物（一旦我們在 conda-forge 中實現這一點，這將適用於已簽署的套件）：https://search.sigstore.dev/?hash=7559cc269e98f41ca9e97ccbcfeadcecf177f2e2a744caf1f6e5b2604d8b5d43
- 關於如何確保維護者不會開始隨機添加未進入 conda-forge 生產管道的證明的問題。這些額外的證明會為在 GH 中檢查證明的官方方式增加「雜訊」，因此也許我們必須將「好的證明」複製到我們完全控制的服務/儲存空間。也有人認為證明本身會告訴你哪個套件在哪裡構建，所以只要使用者注意，就沒有「雜訊」。
- 現在是重新檢視 OCI 上傳和權限的好時機，因為它們在範圍上似乎相似。
推遲到下次會議
- [ ]
CFEPs
- [ ]