跳到主要内容

2018-08-07 conda-forge 会议

置顶项目


新项目

  • 投票程序修改: https://github.com/conda-forge/conda-forge.github.io/pull/612
    • 已合并
    • MichaelS 欠一个关于当前 run_exports 最佳实践的文档 PR
    • MVN 欠一个关于双编译器输出的 CFEP
  • 小组提案:设立在核心会议之外以不同频率举行会议的小组
    • 每个提案都需要提交(至 ????),然后需要核心投票才能创建。每个提案应包含小组的范围和初始成员,以及小组预计如何协调和沟通。
    • 提议的初始小组
      • bot:负责 bot 架构、实施、维护的人员。非 bot 的实际用途(例如,创建大型迁移)
      • fiscal:如何从 NumFOCUS 分配资源/定期批准支出
      • toolchain:编译器,何时更新到新的 ABI
      • R 生态系统
  • NumFOCUS 峰会: http://summit.numfocus.org/pages/schedule.html
  • Conda 4.5.9 (功能相关)
    • Filipe 请求一个选项,如果 conda 尝试使用优先级较低的通道中的软件包而不是优先级较高的通道中的软件包时报错。允许回退,但仅针对不存在的软件包。
  • Dougal 提出 conda-build 创建 noarch 软件包的问题。Conda-build 想要使用新的 python,然后遇到无法满足的依赖项(python 3.7 尚未完全构建完成)。

现有项目

  • 讨论 defaults 和 conda-forge 之间 recipes 的同步以及我们面临的一些问题
  • 共享密码(在下次会议开始时)
    • 尝试一些方法,然后继续处理更有趣的问题
    • 让我们尝试 KeyBase。Eric D. 刚刚向大多数核心团队成员发出了邀请。
  • 确定迁移的后续步骤/行动项/gh 问题
    • MVN 将与 CJ 协调,为那些需要编译器但实际上没有明确指出的内容发布 PR。
    • 解析图表,找到所有可能是 py 3.7 但没有编译器且不是 noarch 的内容,对其运行重建。
    • 在重建图表时,可能需要两个版本的 pinnings + smithy。
  • 决定维护者停止维护的策略
    • 稍后返回
  • 与大约 2k 个待处理的 bot PR 相关…
    • MVN 将给 CJ 一份已关闭但未合并的合并冲突 feedstock 列表。
    • 自动关闭过期的 PR
    • 自动删除已关闭/合并的 bot PR
  • run_exports 投票 https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/102
  • 将“旧” PR 过期(即,使用 bot 自动关闭)到 staged-recipes 中?
    • 添加标签,添加消息(过时),ping 相关方以关闭
    • 决定策略
  • 寻找在核心成员之间共享密码的良好解决方案
  • 在 C3I 上构建软件包并上传到 conda-forge
    • Anaconda 内部 PowerPC 的基础镜像中缺少 Make。真有趣!
    • Mike 欢迎其他人协助处理此事。如果有兴趣,请联系!协助意味着尝试 recipes,调试任何问题,并解决自 Mike 上次拉入它们以来发生的任何合并冲突。目标不断变化。
    • 已构建的软件包 https://anaconda.org/cf-cb3 - 这些可能需要在版本方面做更多工作。图表是使用版本计算的,但可能应该忽略它们。当 pin 比新的 recipe 旧时,由于版本不匹配,上游 recipe 会被忽略为真正的依赖项。
  • 再次公开议程和 notes。
    • John 将看看我们是否可以使 dropbox paper 对全世界可读
    • 其他选择是在会议结束后将 notes 发布到公共场所
  • conda-forge 博客

讨论项目

  • 完成编译器迁移讨论 (参见: +2018-07-17 conda-forge 会议 )
    • 当前状态更新
      • 剩余需要语法迁移的软件包数量
      • 需要重新编译的软件包数量
        • 准备就绪的总数
        • 第一层中准备就绪的数量
      • 对于构建时非静态的新事物,构建编号增加 N
        • 使用 conda render clobber 文件确定构建编号
    • 决定迁移顺序 [结果:制作 py37 + 编译器(使用一个 walker 运行)的超级图表,当 3.7 开始时删除 3.5]
      • py37
      • 编译器
      • 剩余的编译器语法
    • 决定资源策略 [结果:全部在线完成]
      • 离线(没有 CI)
      • 在线(有 CI)
    • 决定通道策略 [结果:为新编译器添加新标签,运行两个标签]
      • 将重新编译的软件包上传到新标签,并继续推送到当前标签
      • 将重新编译的软件包上传到当前标签,将当前时代编译器的更新推送到不同的分支

完成