跳转至主要内容

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
    • 想法是将一些 pinning 文件声明为 pinning epoch
    • 然后我们使用 epoch 的 pinning 和最新的 pinning 渲染配方
    • 讨论维护者的负担
      • 选择加入 vs 选择退出模型
    • 讨论我们想要支持多少个 pinning epoch
      • 当前建议 (Uwe) 最多 2 个 pinning + 最新
      • 每 6 个月到一年左右标记 pinning epoch，这将创建一个大约每年的弃用周期
    • 机器人将需要发布 PR 以将 feedstock 更新到下一个 pinning 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 在此方面的工作！有来自 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 日起停滞
    • 关于移动到 “broken” 与从 conda-forge 频道删除的积极辩论
    • 活跃投票，于 2020-03-11 结束
    • 投票结果是什么？
    • 我们收到 NumFOCUS 的回复了吗？

  • cfep-17 处理 pin backport 和依赖项重建

    • 关于 Isuru、CJ 和 Matt 之间实施细节的停滞辩论
    • 2020-07-22 更新：我们原则上同意在临时基础上（即，直到迁移结束）直接在 feedstock 中渲染所需的额外 pinning。

讨论​

检查之前的行动项目​

从上次会议议程复制之前的行动项目。

本次会议​

  • 弄清楚如何向用户传达重大更改。可能应该立即提出问题以进行进一步讨论。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 问题跟踪器
  • Jonathan 将更新文档，以记录一些非详尽的软件包列表（如 cuda-toolkit、MKL 等）
  • Jonathan 将审查此 PR

3 次会议前​

移动到 Issue Tracker​

  • (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？
    • 非正式信息：角色、日常工作、简历、所有信息、您为何在此处等等。
    • 公开还是内部？我真的不在乎。有人强烈反对吗？
    • 选择加入公共简历
    • 软件木工有大量讲师，并且有 https://carpentries.org/instructors
    • 一些关于 “又一个地方来保持内容更新” 的担忧
  • (CJ) 组建财务子团队
  • (ED) 记录使用 conda-forge 的可重现环境的策略
  • (UK) 静态库内容
    • 添加 linting 提示到构建以找到它们
    • 推荐如何打包它们 -> CFEP-18
    • 我们应该编写文档说明我们不提供支持，这是一个坏主意。 -> CFEP-18