2016-07-22：一般讨论

时间：14:00 UTC

Hangout 链接：https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie

与会者

John Kirkham

Jonathan Helmus

Matt Craig

Phil Elson

Michael Sarahan

Filipe

常设事项

有多少个仓库？
有多少贡献者？
新的核心开发者？

议程

正式提出和决定增强功能的治理/机制。
```
*   Motivation:  Without a formal governance model it is difficult for the conda-forge  community to reach final decisions.  There is no designated place to  propose changes in, e.g. compiler infrastructure or whether to run or  not to run a package's unit tests, so these end up being scattered  across pull requests and issues.
```
- 治理模型
```
    *   The Python model: BDFL + PEPs
```
  - Jupyter 模型：BDFL + 指导委员会 + JEP：https://github.com/jupyter/governance
  - astropy 模型：协调委员会 + APE：https://github.com/astropy/astropy-APEs 和 http://www.astropy.org/about.html
  - IPEP : https://github.com/ipython/ipython/wiki/IPEP-0:-IPEP-Templatehttps://github.com/ipython/ipython/wiki/IPEP-0:-IPEP-Template
  - numpy 治理：https://docs.scipy.org.cn/doc/numpy-dev/dev/governance/governance.html
  - 所有这些模型都有一种增强提案机制，那么创建 github.com/conda-forge/conda-forge-enhancement-proposals 怎么样？
SciPy sprint：https://trello.com/b/KURmGkly/conda-forge-scipy-sprint
conda-forge 代码行为准则文档：https://docs.google.com/document/d/10dxX0Zse0Rx1HqsxC73Wfsghmy5m8PP8cHuBIOhWKpc/edit
讨论一些联系作者的指南
Feedstocks 理念：显式 vs 隐式 / 可重现 vs 冗余
OSX - 恢复到可用、连贯的堆栈
```
*   libc++ (clang) vs libstdc++ (gcc/g++)
```
- clang 所需的最低 OSX（我认为是 10.8？）
- 实际上，clang 从 10.7 开始就可以使用。因此，考虑到您的兼容性约束，这将是可行的。
- 此外，我看到的所有参考文献都表明这将仍然具有 C++11 支持。
- 与默认设置（在 10.7 上构建，使用 gcc）的兼容性 - 人们会在哪里中断？我认为只有在混合软件包时 - 我们如何确保我们拥有所有需要的软件包？
改进基础设施
```
*   Travis CI API issues
```
- 完成 GitHub API 问题
- 使用 staged-recipes 获得更好的工作流程
底层打包
PR 到 staged-recipes 的基本社区实践。
无需重新讨论这个问题。我仍在编写文档，如果准备就绪，我将在明天（或 SciPy 之后 ;-) 发送链接
NetCDF（~~还有 curl/ca-certificates 和 Perl 软件包~~） - 完成了吗？
```
*   curl and ca-certificates are done and available. 
```
- Perl 不再是此过程的一部分
通知（我们如何掌握它们）

标准化安装

*   Mention [`toolchain`](https://github.com/conda-forge/toolchain-feedstock) .

        *   Discuss rollout to feedstocks.

*   Get feedback on [`python-toolchain`](https://github.com/conda-forge/staged-recipes/pull/642) 

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?
```
- 我们允许哪些类型的二进制数据（如果有）（例如图标）？
- 我们如何验证许可？
- 我们如何验证它们是否安全？
OpenBLAS（在 Windows 上）

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

*   Do we do them at conda-forge?

        *   Maybe add a label.

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

我们如何强制执行我们决定的任何内容？

Conda-forge 安装程序
```
*   We have Python 3.5, and 3.4 now. Would be nice to have 2.7.
```
- 拥有所有内容。虽然 conda-build 需要一些工作。
- 安装程序的仓库存在，但仍有许多问题悬而未决。（https://github.com/conda-forge/conda-forge-anvil）

频道镜像

*   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... =(

Docker 托管解决方案
```
*   Docker Hub builds were broken for a week and a half.
```
- 目前已切换到 quay.io。
- 在 Docker Hub 上镜像 quay.io 镜像。
- 关于 quay.io 的想法？关于一般托管的想法？
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 验证：最好是折中，而不是分歧。conda-build 可能会集成 anaconda-verify，如果 conda-forge 在此处添加元数据会很好。
Google hangouts 的最大容量为 10。是否值得考虑其他沟通方法，以便每个想参与的人都可以参与？
也许这个（http://www.freeconferencecalling.com/）是一个选项。
Bluejeans
Continuum 拥有 Webex。过去的经验是，某些 Linux 平台连接有问题
删除 numpy 1.10 并减少我们的构建矩阵。（Numba 现在可以使用 numpy 1.11。）
来自 graphviz 的 PR 的这条评论是我见过的最好的摘要：conda forge/staged recipes#568#issuecomment-225315370
感谢指出这一点。所描述的解决方案看起来是合理的，并且比前缀软件包名称更可取。太棒了！
有什么好处？
我们会区分库和独立工具，类似于 Debian 吗？我强烈建议这样做，因为它是 (1) 已建立的，并且 (2) 对用户来说更容易访问（如果他想使用库，他知道语言。如果他想使用独立工具，他不在乎）。（）https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names）
会有精心策划的行动吗？如果没有，我们如何处理不一致和潜在的冲突（同时安装 python-h5py 和 h5py）。
```
*   we will probably go with meta-packages for conflicting packages
```
签名软件包
应该很容易做到。（http://conda.pydata.org/docs/signed-packages.html）
之前有人对此感兴趣。
HTTPError: 503 Server Error: Service Unavailable: Back-end server is at capacity for url...
似乎我们在正常使用条件下经常遇到此问题。
之前讨论过在 AppVeyor 上缓存软件包并尝试重用这些软件包作为开始。
也许我们需要考虑在所有 CI 上进行缓存。
使用 constructor 构建我们自己的类似 Miniconda 的自解压脚本，其中包含软件包。
Continuum 方面已经进行了一些改进，应该对此有所帮助。简而言之，repodata（给定频道的软件包索引）是为每个 anaconda.org 查询生成的。这是不必要的高成本，并且已经实施了一些缓存方案。
处理删除未固定/错误固定的软件包。
到目前为止是手动完成的。
但这不能很好地扩展。
我们应该（半）自动化删除吗？
我们应该热修复损坏的软件包吗？（conda forge/conda forge.github.io#170）
Travis CI API 不可靠

笔记

873 个仓库，171 人
讨论添加新的核心开发者和引导新的贡献者
治理/增强提案
- https://github.com/ipython/ipython/wiki/IPEPs:-IPython-Enhancement-Proposals
- 想要一个地方来移动更长的技术讨论，这些讨论最终将转变为决策
- 过去增强提案的用例
```
*   compiler decisions (one per OS)
```
  - CentOS 5 vs 6
- 增强功能与如何做出决策
```
*   core group which votes on the issue?  Others from the community?
```
  - 提案应提供证据，以帮助其他人理解问题
- 增强提案定期合并
```
*   "pending" status on issue where no decision has been made
```
- 没有 BDFL，而是委员会（astropy 有协调委员会，numpy 有指导委员会）
- 增强提案提案拉取请求 -- Jonathan
- 迭代以实现类似 numpy 的治理

关于 conda-forge sprint 的博客文章 -- Filipe
行为准则
```
*   Filipe has draft, please review
```
- 我们如何处理那些行为不端的人（在文档中指定）
- 作为增强提案提交，大约 1 周后提交审查
- 委员会将担任行为准则小组的保姆角色（可能是一些外部人员）
联系作者 -- ping 4/5 位活跃贡献者，以告知并询问他们是否愿意贡献
```
*   do not add people to list of maintainers without permissions, let them add themselves in a pull request
```
- 将常用代码片段添加到文档中，以便更容易找到并被其他人使用
- John 将在通过 PR 联系贡献者的指南中添加通用评论。
在 SciPy 上多次提及和兴奋 conda-forge
```
*   Time-series on big packages mentioned at SciPy?
```
- 关于 Nathan 的 whl 演讲的一些问题
像默认设置一样将 gdal 拆分为 libgdal 和 gdal，似乎已解决问题
下次会议在 3 周后的今天，8 月 12 日