2016-06-24：一般性讨论
（请注意，此文档先前错误地将会议安排在 17 号）
时间：14:00 UTC
环聊链接：https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie
与会者
Filipe
Jonathan Helmus
Matt Craig
常设事项
- 有多少仓库？
- 有多少贡献者？
- 新的核心开发人员？
议程
-
底层软件包
-
拆分 gcc 还是使用 defaults？我们需要一种更好、更一致的方式来构建依赖于 Fortran 和 libgomp 的软件包，否则当混合使用 conda-forge 和 defaults 时，我们将不断看到损坏的软件包。
-
向 staged-recipes 提交 PR 的基本社区实践。
-
最近我在 DC 的 NOAA/IOOS 中介绍了 conda-forge。大多数人对 conda-forge 感到兴奋，但不愿意从 IOOS 频道切换到 conda-forge。当然，主要原因是控制。我尽力向他们保证，conda-forge 将遵循所有良好的社区实践，就像他们已经依赖的任何其他开源项目一样。但是，仍然存在一些担忧。我想在我们的会议上介绍一下讨论的摘要。
-
NetCDF（
还有 curl/ca-certificates 和 Perl 软件包）- 完成了吗？* curl and ca-certificates are done and available.- Perl 不再是此过程的一部分
-
GitHub 速率限制。我们如何进一步缓解这些？这是一个重复项，它再次出现在下面。 -
PR 审查
* Treat every PR as a Work in Progress. At least let PRs sit for a few hours before merging them.- 当我们提出澄清问题时，请等待答案，并在获得答案之前避免采取行动。
- 尊重第一位审阅者，不要用另一种说法重复她/他的审阅意见。这对提交 PR 的人来说也是不利的，因为它会造成混淆。
- 避免千刀万剐：许多小的“吹毛求疵”的评论可能会吓跑新的贡献者（@ Mike S ;-)
-
通知（我们如何掌握它们）
-
标准化安装
* 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
* Discussing Ray Donnelly's work on MSYS2 packages and how we want to use and integrate these into 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 now- 仍然需要
conda。 - 新的仓库？
- 我们将安装程序托管在哪里？Git 标签？
- 仍然需要
-
GitHub 速率限制。我们如何进一步缓解这些？
* GitHub letter ( [](https://docs.google.com/document/d/19HLtYPwg6IKAwmxPwL7Vd3AX0n47ANP-ZTpZROn-Cwc/edit?pref=2&pli=1)https://docs.google.com/document/d/19HLtYPwg6IKAwmxPwL7Vd3AX0n47ANP-ZTpZROn-Cwc/edit?pref=2&pli=1 ).
* +1, this reads very well
* +1 also -- is it appropriate to ask for advice on how to reduce our API calls or queue them up in the event they are unwilling to raise limit?
* So, there have been updates since this was initially added. See this issue ( [conda forge/conda forge.github.io#88](https://github.com/conda-forge/conda-forge.github.io/issues/88) ). They wrote this letter in reply ( [](https://docs.google.com/document/d/1lzWNxvmEtrgjSBVrUWEO-imDryBOLRfObz3PkI9qT5Y/edit?pref=2&pli=1)https://docs.google.com/document/d/1lzWNxvmEtrgjSBVrUWEO-imDryBOLRfObz3PkI9qT5Y/edit?pref=2&pli=1 ). Basically, they said that it wouldn't make sense for them to bump our rate limit in this way as our current usage scales poorly. I think I agree with that sentiment. Wrote up this proposal for more optimizations ( [conda forge/conda forge.github.io#172](https://github.com/conda-forge/conda-forge.github.io/issues/172) ). Have done some of them. See this PR ( [conda forge/staged recipes#733](https://github.com/conda-forge/staged-recipes/pull/733) ) for part of the fix. This has greatly improved the situation. Though we still have some issues. -
频道镜像
* Can this point be a little bit explained? I thought about this as well and would like to contribute to this point. -
Feedstock 历史
* Is it sacred?-
我们是否 rebase/force push？
* If so, under what conditions?- 我们如何避免多人同时执行此操作？
-
-
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 个字符）和描述（无限制）
-
Google 环聊的最大容量为 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
-
感谢指出这一点。所描述的解决方案看起来是合理的，并且比前缀包名称更可取。太棒了！
-
签名软件包
* Should be easy to do. ( [](http://conda.pydata.org/docs/signed-packages.html)http://conda.pydata.org/docs/signed-packages.html )- 之前有人对此感兴趣。
-
HTTPError: 503 Server Error: Service Unavailable: 后端服务器已满负荷，网址为...
* Seems we are regularly running into this issue under normal usage conditions.- 之前讨论过在 AppVeyor 上缓存软件包并尝试重用这些软件包作为开始。
- 也许我们需要考虑在所有 CI 上进行缓存。
- 通过
constructor构建我们自己的类似 Miniconda 的自解压脚本，其中包含软件包。
笔记
最紧迫的问题：命名约定
命名约定
-
Continuum 的意见：命名空间生效需要一些时间，不想破坏任何人的设置，所以保留当前名称，我们可以遵循 defaults，其中 defaults 具有优先权吗？在 Continuum 没有软件包的地方，他们可以遵循 conda-forge 吗？
-
simplegeneric 问题，冲突
-
当您执行“conda install gplot”时，如何知道安装了哪个软件包？导致可重现的环境。
-
从没有命名空间开始，在安装“核心”软件包（python、r 等）后获取命名空间，然后您将获得与您的环境中的语言匹配的软件包
-
希望 conda 的行为类似于 pip、cran 等，“开箱即用”
-
如何处理依赖项？
-
建议当您安装一个软件包时，您将获得所有命名空间中的软件包？
-
另一种选择是在软件包名称中指定语言（python-simplegeneric），并为“常用”软件包设置查找表
-
应该在 conda GitHub 仓库上提出问题
-
没有简单的解决方案，但我们需要选择一些解决方案
-
使用“常用”名称的元软件包
-
正确的解决方案是用“python-”前缀所有内容，但是人们在安装时不想这样做，并且人们已经习惯了旧方法。
-
Filipe 关于命名空间的问题是它为用户做出了选择，宁愿让用户自己选择...在 GitHub issue XXX 上提出
-
对于许多用户来说，conda 是 pip 的直接替代品，我们应该保持这个巨大的优势吗？
-
是否有比命名空间工程性更低的解决方案？
* Should be raised in GitHub, submit PRs -
前缀所有内容并让 conda install 智能地查找这些软件包？
-
不要前缀 defaults 中的软件包，但 defaults 中没有的任何内容都应该前缀 python-、r-
-
在 PR 中发布玩具示例到 conda，看看它是否有效？
-
稍后继续讨论...
骨架生成器
- 骨架生成器应该使用前缀名称吗？
- 骨架需要一些更新，不
- John 有 Jinja 模板，可以生成 meta.yaml，我们可以使用这个吗？需要从 setuptools 中提取数据
- conda-forge 应该发布自己的骨架生成器吗？还是其他不同的东西
治理
-
NOAA 担心失去对仓库的控制
-
担心仓促合并的 PR 和类似问题
-
为好的 PR 应该是什么样子、自我合并和类似问题编写指导提案
NumPy 问题
- libgfortran 会解决这个问题吗？
- 希望 Micheal Grant 在创建 conda-forge libgfortran 之前查看求解器
- libquadmath，当前计划包含在 libgfortran 中，defaults 中未使用，这些应该是单独的软件包吗？
- libstdc++
- 需要在 conda-forge 和 Continuum 之间标准化通用编译器堆栈
对 Phil 的优先事项的建议
-
conda-build-all
* [SciTools/conda build all#41](https://github.com/SciTools/conda-build-all/issues/41)
在 conda-build 的 beta 版本上运行构建的服务
“稳定”软件包的副本？
- 将多个 PR 合并到单个版本中
- conda-build-all PR