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) 我们都已更新,10 月损益为零
-
公开投票
- 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 年和 2020 年每年增加了约 3k 个 feedstock
- 我们存储的数据量增长似乎正在加速
- 风险衡量
- 一些数字
- 今天由于我自身限制,将跳过
- TODO
- 每个人都看看 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 requirements 要么被发现是必需的,要么是可疑的 imports,则 feedstock 是“准确的”(从 depfinder 的角度来看)。可疑的 imports 是指被模糊处理的 imports,以至于它们可能不会被运行(在函数内部,在 try except 之后等)
- 审计是在源代码本身上运行的,而不是在生成的
site-packages
上,因此我们原本不会发布的 files(tests, examples, etc.)可能会被纳入审计。 - 审计对可选文件没有太多可见性,因此我们假设所有文件(及其相关的 imports)都是必需的。这可能会导致 depfinder 认为 conda-forge 的规格不足。
- 如果一个 feedstock 需要一个 pkg,该 pkg 会覆盖其他 pkgs,那么我们可能会丢失 requirements,因为这些 imports 在形式上是由覆盖 pkg 提供的
- 这些审计可以构成以下工作的基础
- 修复我们缺少必需依赖项和传递依赖项的依赖关系
- 修复上游需求规范,并确定上游规范在 pkg 需求级别上的可靠性
- 帮助维护者围绕依赖项更新做出明智的决定
- 审计源代码: https://github.com/regro/cf-scripts/blob/master/conda_forge_tick/audit.py#L39
- Import maps: https://github.com/regro/libcfgraph/tree/master/import_maps
-
(MRB) 打包 ray
- 我们有一个可用的 recipe: 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
- 我们需要一个政策。
- TODO
- MRB: 提交 50% 投票
-
(MRB) artifact-validation 和前缀中的 clobbering
- 请看这里: https://github.com/conda-forge/artifact-validation
- 其工作原理如下
- 当软件包复制请求发送到 heroku 服务时,它会发送 artifact 以通过 GHA repo dispatch event 进行验证
- 此事件在 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
Docs
staged-recipes
website
security+systems
CI infrastructure
Compiler upgrade
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 中呈现所需的额外 pinnings。
讨论
检查之前的行动项
从上次会议议程复制之前的行动项。
本次会议
2020-11-24
上次会议
2020-11-18
- (IF/MRB/MV) intel oneAPI
- todo
- (Nikolay) opencl_rt 的许可
- (Nikolay) intelmpi ABI 与 mpich 的兼容性
- (MRB/IF) 弄清楚如何准确打包 C/C++ 编译器
- (MRB/IF) 考虑 fortran ABI
- (MRB) 创建 conda-forge 编译器室(添加人员,包括 keith)
- todo
- (MB) 要求核心成员转为 “emeritus” 状态
- TODO: Eric 设置所有核心成员的季度检查,以查看他们是否有兴趣保持 “active” 状态,或者他们是否想转为 emeritus
- 从具有访问各种凭据(api tokens,twitter 密码等)权限的人员中删除 emeritus 人员? 这将需要更改治理文档。
- TODO: Eric 设置所有核心成员的季度检查,以查看他们是否有兴趣保持 “active” 状态,或者他们是否想转为 emeritus
两次会议前
2020-11-11
- TODO: 考虑引入 JOSS,以提供关于我们如何最好地撰写论文的背景信息
移至问题跟踪器
2020-11-03
- (MRB) 关于核心人员在他们不维护的 feedstock 中推送的拟议政策 * [x] (MRB) 放入文档 PR * [ ] (MRB) 在 bot 上创建 PR 以提及该政策
- TODO: 检查 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 名称更改
- 将目标平台添加到哈希值
- 使用 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 模板以将机构合作伙伴 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 构建 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) 更新关于如何向 feedstocks 添加 CUDA 支持的文档
-
(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) 静态库 stuff
- 向构建添加 linting 提示以找到它们
- 推荐如何打包它们 -> CFEP-18
- 我们应该编写文档说我们不提供支持,这是一个坏主意。 -> CFEP-18