2016-08-25: 一般讨论

时间：14:00 UTC

在线会议链接：https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie

与会者

Jonathan Helmus, Filipe, Michael Sarahan, John Kirkham, Jake VanderPlas, Eric Dill, Ray Donnelly , Phil Elson

常设事项

有多少仓库？1035
有多少贡献者？212（包括一些机器人）
新的核心开发者？

笔记

邀请 Peter M. Landwehr (pmlandwehr) 参与审查 staged-recipes。我们是否应该给这类人一个头衔，Filipe 将会联系。
大规模治理开源项目：来自维基百科成长之痛的教训 | Staurt Geiger https://www.youtube.com/watch?v=ZSQJYEVcMWM&index=89&list=PLYx7XA2nY5Gf37zYZMw6OqGFRPjB1jCy6
增强提案文档，Jonathan 有笔记，稍后今天会整理出来。
治理文档 - 欢迎帮助。还有“who's who”或“关于”页面。https://conda-forge.github.io/#about
```
*   This page could be expanded, should mentioned these meeting.
```
从议程中移除事项
```
*   Prioritize items on agenda which we should/must talk about.
```
- 交叉链接事项到 GitHub issues/讨论

状态页面：https://conda-forge.github.io/status/

*   Linked to "status" repo:  [](https://github.com/conda-forge/status)[https://github.com/conda-forge/status](https://github.com/conda-forge/status)

conda-forge 代码行为准则 - Filipe 仍在努力

许多团队正在研究新的构建系统：Filipe，Phil，Continuum

*   Continuum's  plan would allow others to add build workers, perhaps conda-forge could  use these in addition to the CI services, especially for long builds

组织新的会议来讨论这个话题

开源 Anaconda Build，我们应该推动发布吗？

*   Would be helpful to have our own build system rather than being dependent on CI systems.

如果我们降低并发性，Travis CI 可以增加时间
```
*   Can we switch between longer time and concurrency?  How much work is this?
```
- 可能目前不接受该提议
- 最好在某处找到可信的硬件
- 用于 OS X 构建的 Vagrant，我们可以研究一下

安全

*   If user changes name and someone takes old name can be a security issue:  [](https://groups.google.com/forum/#)[https://groups.google.com/forum/#](https://groups.google.com/forum/#%21topic/rustlang-security-announcements/BK_3gbXhSn4)[!topic/rustlang-security-announcements/BK_3gbXhSn4](https://groups.google.com/forum/#%21topic/rustlang-security-announcements/BK_3gbXhSn4)

可以通过使用唯一的用户 ID 而不是 GitHub 用户名来解决
想要 Anaconda.org 的令牌，允许写入单个软件包（Phil 将推动 Continuum 处理此事），而不是全局写入。

元数据统一
```
*   Should conda-forge include additional metadata which would make it easier for Continuum to re-use recipes
```
- 这应该是必需的还是可选的？
```
    *   Required would likely reduce number of contributors
```
  - 将需要时间/工作来将这些添加到所有当前软件包
  - 添加到 linter 和 conda skeleton
    * Make linter have "warnings" not hard fails
  - 其中许多似乎是冗余的，我们可以重用现有的元数据吗？
- 许可证文件可能应该是必需的
```
    *   Legal vs. suggested
```

议程

将议程事项标记为完成。
分享状态页面。:) 还要弄清楚如何有效地定向通知。
增强提案文档更新。
conda-forge 代码行为准则文档：https://docs.google.com/document/d/10dxX0Zse0Rx1HqsxC73Wfsghmy5m8PP8cHuBIOhWKpc/edit
提及 Travis-CI 提供更多 CI 时间。
我们可以考虑将您的构建时间增加到 180 分钟，但我们可能需要将您的默认并发数从 5 个作业减少到 3 个，因为您将在很长一段时间内使用多个虚拟机。
提及/讨论 Travis Oliphant 关于开源 Anaconda Build CI 的评论。
安全
Feedstocks 哲学：显式与隐式 / 可重现与冗余
与 Continuum 的元数据统一 - 我们是否可以接受在 about 部分添加一些字段以匹配 Anaconda 标准？
包含许可证文件
许多配方不包含许可证文件。
几乎每个许可证都有关于提供许可证的条款。
我们是否应该开始要求这个字段。
注意一些开发者也没有包含许可证文件。
在某些情况下，让他们这样做很困难。
CUDA/cuDNN 更新

改进基础设施

*   Better workflows with staged-recipes

        *   Fast finish AppVeyor on merge ( [conda forge/staged recipes#1142](https://github.com/conda-forge/staged-recipes/pull/1142) )
*   Drop Travis CI matrix ( [conda forge/staged recipes#1234](https://github.com/conda-forge/staged-recipes/pull/1234) )
*   Use CircleCI for feedstock generation ( [conda forge/staged recipes#916](https://github.com/conda-forge/staged-recipes/issues/916) )
*   Keeping recipes out of PRs ( [conda forge/staged recipes#942](https://github.com/conda-forge/staged-recipes/issues/942) )
*   Bank work in partial conversion ( [conda forge/staged recipes#915](https://github.com/conda-forge/staged-recipes/issues/915) )

通知（我们如何掌握它们）
MSYS2
```
*   Available on defaults - was in conda 4.1.7, but that was pulled.  Coming in 4.1.8.
```
- 讨论 Ray Donnelly 在 MSYS2 软件包方面的工作，以及我们希望如何使用这些软件包并将它们集成到 conda-forge 中。
- 需要考虑的一些用例 OpenBLAS，FFTW，构建工具，其他？
二进制数据
```
*   Do we include it in recipes?
```
- 如果允许（例如图标），我们允许哪些类型？
- 我们如何验证许可？
- 我们如何验证它们是安全的？

开发版本：它们在哪里发布？

*   Do we do them at conda-forge?

        *   Maybe add a label.

*   Do we let others do them with a feedstock on their own repo?

我们如何执行我们决定的任何事情？

频道镜像

*   Can this point be a little bit explained? I thought about this as well and would like to contribute to this point.

        *   Eric Dill has put together a script for copying a package from one channel to another here: [conda forge/conda forge.github.io#134](https://github.com/conda-forge/conda-forge.github.io/pull/134)
*   I have a really, really crude script that copies all of the packages in one channel to another that I just put at: [](https://gist.github.com/mwcraig/8473cf840f6d29236d6d8af699404555)[https://gist.github.com/mwcraig/8473cf840f6d29236d6d8af699404555](https://gist.github.com/mwcraig/8473cf840f6d29236d6d8af699404555)
*   conda-build-all can copy from one channel to another: `conda build-all --inspect-channels conda-forge --upload-channels astropy some_packge_recipe` will copy the `some_package`  from the channel conda-forge to  astropy if it can, or build it if it  doesn't exist on conda-forge. Discussion  about what the desired  behavior should be has started at: [SciTools/conda build all#46](https://github.com/SciTools/conda-build-all/issues/46)

Feedstock 历史

*   Is it sacred?

我们是否 rebase/force push？

    *   If so, under what conditions?

我们如何避免多人同时执行此操作？

        *   I don't think you can.

*   IMHO,  if it's just one author in staged recipes, sure.  If feedstock, no  force push - only to PRs to feedstock.  If people don't mind merge PRs,  it sure is a lot simpler to not rebase.  I have messed up rebasing a few  times recently... =(

Continuum 元数据请求：我们可以将这些添加到 linter 吗？
```
*   example metadata: [](https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44)[https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44](https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44)
```
- 此外，区分摘要（限制为 77 或 80 个字符）与描述（无限制）
- Anaconda verify：最好在中间会合，而不是分歧。conda-build 可能会集成 anaconda-verify，如果 conda-forge 在此处添加元数据会很好。
删除 numpy 1.10 并减少我们的构建矩阵。（Numba 现在适用于 numpy 1.11。）

软件包签名

*   Should be easy to do. ( [](http://conda.pydata.org/docs/signed-packages.html)[http://conda.pydata.org/docs/signed-packages.html](http://conda.pydata.org/docs/signed-packages.html) )

以前对此有一些兴趣。

HTTPError: 503 服务器错误：服务不可用：后端服务器已满，网址为...
```
*   Seems we are regularly running into this issue under normal usage conditions.
```
- 之前讨论过在 AppVeyor 上缓存软件包并尝试重用这些软件包开始。
- 也许我们需要考虑在所有 CI 上缓存。
- 通过 constructor 构建我们自己的类似 Miniconda 的自解压脚本，其中包含软件包。
- Continuum 方面已经有所改进，应该对此有所帮助。简而言之，repodata（给定频道的软件包索引）是为每个 anaconda.org 查询生成的。这是不必要的高成本，并且已经实施了一些缓存方案。
处理删除未固定/错误固定的软件包。
```
*   Has been done manually thus far.
```
- 但这不能很好地扩展。
- 我们应该（半）自动化删除吗？
- 我们应该热修复损坏的软件包吗？ ( conda forge/conda forge.github.io#170 )
- 我们应该将它们标记为损坏
当前不可构建的软件包
```
*   In particular open source code that is out of scope for CIs.
```
- 示例包括 Qt4，Qt5，可能 PyQt4，可能 PyQt5，gcc，VTK 等。
- 我们如何指示它们是手动构建的？
- 我们是否可以接受上传非构建的二进制文件？
- 我们何时确定某件事可以手动构建？
- 人们在手动构建时应遵循哪些程序？
```
    *   Use a standard build docker image, VM, or vagrant file
```
  - 签名软件包？
  - 在可行的情况下实施可重现的构建（linux）
    * [](https://reproducible-builds.org/)[https://reproducible-builds.org/](https://reproducible-builds.org/)
  - 我们需要在 conda-smithy 其他地方进行哪些更改？
- 我们还可以利用哪些其他构建基础设施？
```
    *   Would  be nice to provide some volunteer builder abstraction, so that we could  have an elastic worker farm that would be somewhat resilient.
```
  - 标准化构建镜像可能（相对）容易 - 但如何协调呢？
分阶段发布
Windows BLAS 解决方案
```
*   Still don't have a BLAS for Windows yet need something.
```
- 不构建 BLAS
```
    *   NumPy has a small subset of BLAS functionality.
```
  - 不确定如何处理 SciPy（也无法找到它们的 Windows wheels）。
  - 仅使用 C 支持构建 OpenBLAS。
    * Will be pretty slow.
  - 应该适用于所有 Python。
  - 使用 MinGW 编译器构建 OpenBLAS。
    * Works with Python 2.7 and 3.4.
  - 不适用于 Python 3.5？
  - 重用类似于 R 的 BLAS 的东西。
    * Is there a package for something like this?
  - 它是否会遇到与 Python 3.5 相同的问题？
  - ATLAS？