2020-08-12 conda-forge 核心会议
与会者
议程
常设议题
- 为电话会议上的新人介绍
- (CJ) 预算
您的新议程项目
-
(MRB) CFEP-13 和团队更新已完成
-
(CJ) 对于废弃的 feedstock,期望的用户体验是什么?我们如何实现?
- 我们目前的用户体验非常糟糕,因为我们的用户与 feedstock 的维护之间存在很大的脱节。这意味着许多用户可能没有意识到 feedstock 处于无人维护状态,或者可能无法自行维护 feedstock。许多用户可能只有在我们不发布关键修复或安全补丁时才会发现问题。
- 我的建议是验证 feedstock 的状态,并在不占用我们维护者额外时间的情况下提供我们尽力而为的支持
- 添加一个 issue,询问 feedstock 是否无人维护(如果 3 个 bot 版本升级 PR 在一个月内没有被处理)
- 如果 issue 没有及时处理(关闭且 bot PR 已合并/关闭)(一个月?),则认为其已被废弃
- 移除维护者并添加一个看护者
unmaintained
团队。这个团队的唯一工作是合并任何添加维护者的 PR(并移除他们自己) - 在 Readme 顶部添加一行,说明 feedstock 处于无人维护状态,并欢迎/鼓励/需要任何新的维护者
- 添加自动合并以及当时可用的任何其他自动化(例如,依赖项更新)
- 我们可以为系统重要性软件包(例如 ruamel.yaml)做出例外
- 需要在安装时提供反馈,说明 feedstock 处于无人维护状态
- 添加无维护者 feedstock(对于那些尚未接受邀请的人)
- 不要移除维护者
- CVE?当新的 CVE 出现在无人维护的 feedstock 上时,我们该怎么办?我们可以生成这些东西的列表吗?
- 提供
- 自动合并?
- R 对严格管理的元数据没有问题
- 另一方面,Python 在依赖项解析方面一团糟。如果我们添加 grayskull 元数据自动更新,那么大多数关于自动合并的担忧就会消失。
- 其他语言呢?
- 上游已废弃的软件包呢?
- 从没有维护者的 feedstock 开始是另一个好的起点
- https://github.com/conda-forge/cfep/pull/15
- 待办事项:在 hackmd 上记录总体策略。
- 推进 CFEP,明确无人维护的含义
- ???
-
(FF) 通过 NumFOCUS 卡支付 Heroku 费用,这将直接从我们的资金中扣款。NumFOCUS (Leah) 也在与 Heroku 联系,看看他们是否可以为我们提供一些特别的免费服务。
-
(FF) AWS 积分:我们有 1k,可能会获得更多。我们必须批准 2 个计划,一个是我们已有的,第二个是额外的,我会问 Andy 我们是否也可以执行。
-
(IF) 来自 AWS 的 Windows 服务器。这将使调试 windows recipes 比在 CI 服务器上调试容易得多。定价在 https://aws.amazon.com/workspaces/pricing/?nc=sn&loc=3
-
AWS 结果
- 我们将提出一个很大的请求,因为这才是有用的。
- 打算要求很多,然后让他们砍价。
- 总计将为 1600 + windows 服务器的成本
- 使用此服务器
- 8 vCPU, 32 GB 内存 80 GB 50 GB $130.00 $9.75/月 + $1.53/小时
-
(IF) macOS arm 正在进行中。
- 目前受 CDN 不支持 osx-arm64 下载的阻碍
- 开始构建 python 依赖项。
- zlib - 必须保护
make check
- bzip2/libffi - 工作正常(在 libffi 上关闭了
test_on_native_only
,因为测试只是存在性测试) - xz/ncurses - 必须运行 autoreconf 以获取新的
config.sub
和config.guess
- ncurses - 必须设置
BUILD_CC
而不是标准的CC_FOR_BUILD
。(我们也应该设置那个) - ncurses - 需要来自构建的 ncurses。 https://github.com/conda/conda-build/pull/4011
- zlib - 必须保护
- 上面一些任务的迷你迁移器
- 使用
CONDA_BUILD_CROSS_COMPILATION
环境变量的条件来保护make check
。 - 将
cmake .
更改为cmake ${CMAKE_ARGS} .
- 使用
- macOS Arm 迁移器改进
- 确定源 tarball 是否有
config.sub
和config.guess
,如果有,则用来自 libtool 的新文件替换它们。 - 如果测试只是存在性检查(如
test -f
),则关闭test_on_native_only
。
- 确定源 tarball 是否有
-
(CHL) conda 4.8.4 于 2020-08-12 发布到 “defaults”;conda-build 版本将在未来一两周内发布。
-
(AS) qgpu - GPU 构建代理。
- Drone 还是 Azure?Drone 是一个简单的 go 可执行文件,你可以在 docker 中运行它。Azure 构建代理是否很重?
- 选择一个并开始
上周我们没有处理的事情
谁在负责这些行动项?
-
(Paul Martin) 从 intel 而不是 Anaconda 重新打包 intel MKL
- 除非 intel 给我们一份书面文件,允许我们这样做,否则我们应该坚持重新打包
- https://github.com/conda-forge/intel_repack-feedstock/pulls
- https://github.com/conda-forge/intel_repack-feedstock/pull/12
- 行动项
- 请求 Intel 就他们对我们重新打包方案的舒适程度提供意见
- 如果他们对直接重新打包感到满意,请请求允许 bot 抓取所需的版本号
- 如果 Intel 对 bot 抓取感到满意,请在 cf-scripts 上提出 issue 以启用
- 在一个月后重新检查,除非事情提前发生
-
放弃 python 3.6
- 需要一个公告周期
- 我们应该遵循 NEP29 吗?NEP29 + 6 个月?
- Python 3.x 版本的生命周期结束
- 3.7 没有 pypy
- 行动项:发送到 issue(从 pypy 团队和其他人那里获取输入)
正在进行的投票
子团队更新
Bot
- 如果 bot 是唯一的提交者,则现在会关闭有冲突的 PR
- Bot 在星期一发生故障,但现在应该已解决
ARM
POWER
CUDA
文档
staged-recipes
网站
安全+系统
见上文
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 中直接呈现所需的额外 pinnings。
讨论
检查之前的行动项
从上次会议议程中复制之前的行动项。
本次会议
上次会议
-
弄清楚如何向用户传达重大更改。可能应该立即打开一个 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 repo 上的 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 添加到迁移 bot
- (Eric) 安排 Anaconda <-> conda-forge 在 anaconda.org 上收集需求同步会议
- 将尝试在下个月安排好。
- (Anthony) 联系 NumFocus,以 выяснить 不在文件中包含许可证的法律后果。
- (Eric) 内部检查酒店和邀请社区人员飞来的资金水平?
- (Eric) 弄清楚 conda-forge 的财务状况以支持自身?
- (jjhelmus) 为我们将要支持的 python 版本打开 CFEP
- (jakirkham) 撰写一篇关于我们今天讨论的 CUDA 内容的博客文章
- (jakirkham) 更新文档,说明如何向 feedstock 添加 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
- 有人担心“又一个需要保持更新的地方”
- (CJ) 组建财务子团队
- (ED) 记录使用 conda-forge 的可重现环境的策略
- (UK) 静态库相关内容
- 在构建中添加 linting 提示以找到它们
- 建议如何打包它们 -> CFEP-18
- 我们应该编写文档,说明我们不提供支持,这是一个坏主意。 -> CFEP-18