2016-07-22：一般討論

時間：UTC 14:00

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://scipy-docs.dev.org.tw/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-ing to 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 伺服器錯誤：服務不可用：後端伺服器已達容量上限，網址為...
似乎我們在正常使用條件下經常遇到這個問題。
之前討論過在 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
- 增強功能 vs 如何做出決策
```
*   core group which votes on the issue?  Others from the community?
```
  - 提案應提供證據，以幫助其他人理解問題
- 增強功能提案定期合併
```
*   "pending" status on issue where no decision has been made
```
- 沒有 BDFL，而是委員會（astropy 有協調委員會，numpy 有指導委員會）
- 增強功能提案提案 Pull Request -- 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 日