# 2017-07-24 conda-forge core meeting

[HackMD link](https://hackmd.io/P8on5P8wR3q3WslwrJzOEg)
[Zoom link]()
****
## Attendees
List the attendees for the meeting

## Agenda

Please add new items to the meeting Agenda

### Scipy Sprints
* [x] Update from conda-forge Sprint (Filipe / Marius / Lori)
* Mugs next year?
* No one really wanted to work on infrastructure.
* Turned into more of a helpdesk -- Still a lot of issues out there. Mostly around documentation.
* How do I handle strict?
* [x] Migration of Robot Operating System (ROS?) packaging ecosystem to conda-forge? Wolf Volprecht -- Who talked to him about this? I just overheard it. Maybe that was Anthony / Michael?
* Wolf is interested in adding these packages to conda-forge. Will probably be handled the same way as "r", so put a "ros-" prefix on the packages. Marius to reach out.
* [x] Pypy implementation proposal: https://docs.google.com/document/d/1DdOEwmG3pr4m9kIktc1crp3dJPdvJjbPvidmEclpuCA/edit
* We have the CI bandwidth to build up the pypy ecosystem -- that's not a particularly painful thing to do. It's mostly around getting these things to even build. pypy has internal versions (6, 7, 8, etc.) that have compatibilities with specific versions of CPython, but the versioning scheme is different.
* Q: How will the pypy variant interact with other variants? It'll be another top-level variant that has to be mutually exclusive with the CPython variant.
* pypy has a different directory structure -- there may need to be changes on the conda side to support `noarch: pypy`.
* Next steps: Say yes / no to the spec, point out potential pitfalls, give it back to (Matti?) and say here's the work that needs to be done.
* Marius did a vague hack at scipy to get stuff building on k8s on Azure. We can probably build anything that is Linux-like for things that take too long for CI. Things TODO: Grab the artifacts and upload them to anaconda.org. This is likely in a state that someone else can pick up and run with.

### Subteam updates

#### Bot

#### ARM
* aarch64/ppc64le [migration](https://conda-forge.org/status/) is nearly complete
* still missing a handful of key packages:
* matplotlib
* notebook (requires pandoc)
* Jonathan: Trying to build a pandoc package for ARM. Right now we've been repackaging a binary. Required for notebook. Might need to convert nbformat back to an arch package
* use matplotlib-core and avoid the qt dep that matplotlib pulls in?
* opencv
* qt
* pyarrow
* CDTs needed for many of these
* possibility of supporting a 32-bit ARM platform, [linux-armv7l](https://github.com/conda-forge/conda-smithy/pull/1115)
* blocked on llvm-dev packages -- can use build-locally.py but someone just has to do it.
* Jonathan: built out compiler packages for arm7. Now smithy & pinnings have the right stuff. There's a couple more things but we can start a migrator soon.

#### Docs

#### staged-recipes

* [ ] [PR #8764 (sextractor)](https://github.com/conda-forge/staged-recipes/pull/8764). Very widely used program in astronomy, the name of the program is `sextractor`, the command line to run it is `sex`. Potential Code of Conduct violation in the name. Proposed alternatives are a different name for the conda-forge package `astromatic-sextractor` or `astromatic-source-extractor`. Even if the name of the package is not `sextractor`, the page on anaconda.org for the package would look something like this, i.e. still several references to `sextractor`:
* widely used, been around forever -- renaming is probably not a good path to pursue
* NumFocus says: The name is bad and it's a possible breaking of the code of conduct. If upstream agrees that it's a bad name and has a commitment to change the name. An issue was opened upstream and the community agreed to change the name of the binary from "sex" -> "sextractor" but not to change the name of the project.
* Matt: Follow up with Anthony on this.


### CI infrastructure

### Please add your name here if you would like to stick something on the agenda

### Eric
1. Anaconda.org maintenance is slow. How can CF push it forward or help maintain it? What are acceptable alternatives if Anaconda.org continues to have slow maintenance and there’s no pathway for CF to contribute to the maintenance?

TO DISCUSS: Who would want access to anaconda.org? Anaconda is going to require an external contractor agreement in place that transfers all IP to Anaconda. You will also need to get a statement from your employer that states that they recognize Anaconda's IP ownership of all contributions you make to the anaconda.org code base. Without both of these documents in place we will not be able to give individuals access to the anaconda.org code base.

* As long as there is a path forward with the new platform that Anaconda is building.
* label management aspect is an important feature for conda-forge.
* working with Anaconda on ensuring whatever feature set exists for the new anaconda.org still matches what the conda-forge community needs.
* TODO: Eric to set up a meeting to document feature set for anaconda.org

2. Switch to Anaconda's webex -- Thanks to Marius / Flatiron Health for all the usage. The 45 minute time limit is something that we should work around.
* Marius: To ping IT and fix the zoom meeting ends in 40 minutes issue.
* Discussion resulted in not migrating to Anaconda's webex.

3. Making meetings public?
a. Publish this meeting agenda on the Monday before the Wednesday meeting and request for community members to attend / add notes to this doc in hackmd?
b. Open issue on github.com/conda-forge.github.io asking for feedback from the community?
c. I guess we get everyone's email from their git commits and email blast the whole community, but that seems like it should be reserved for emergencies
d. Post to public gitter

a. Minutes should be public, meetings should be invite.
b. Alternatively: Give people "read-only" access to the live meeting.
c. Filipe: Research software for audio listen only access for other members of the community that want to attend but aren't part of core.

4. Update meeting invite list. Here are some folks that are on the invite list but do not regularly show up. Should we drop them? Anyone who is a Yes / maybe / probably, I'll email as a group and let them know that we're going to drop them from the invite, but that it's not to be exclusive, just to keep communication lean. They're 100% always welcome to re-join!
* [e-mail]
* Kai Tietz (Anaconda) - probably
* [e-mail]
* Lars Ewe (Anaconda) - yes
* Björn Grüning (emeritus)
* Kale Franz (Anaconda) - yes
* Phil Elson (emeritus)
* Michael Wendt (nvidia)
* Adam Beberg (nvidia)
* Raymond Douglass (nvidia)
* Sophia Parafina (Anaconda) ~~maybe~~ checked with her and she wants to stay involved

Discussion: Leave the list alone. No reason to pull people out of the invite list.

5. Make the core meeting longer?
* Change to 45 minutes for next meeting.

### Marius

1. Intel compiler update.
a. Spoke with David Liu at SciPy about how to use compilers safely. There's a bit of admin involved with the licensing.
b. Marius has a repo that he's working on that outlines this architecture. Will post that soon-ish

## Discussion
Notes from todays core meeting

## Check in on previous action items
* [x] Eric to take over organizing the dev meetings, making notes available, etc.

## New Action items
Copy new action items to next meetings agenda so we can check in.
Make sure each action item is assigned to someone or it will likely not get done.

* [ ] Filipe to open issue about fixing docs -- there were some issues that came up at the sprints.
* [ ] Marius to reach out to Wolf about robot operating systems making it to conda-forge
* [ ] Mike: pypy Next steps: Say yes / no to the spec, point out potential pitfalls, give it back to (Matti?) and say here's the work that needs to be done.
* [ ] Open issue on conda-forge.github.io noting work done on the kubernetes cluster
* [ ] Filipe: Research software for audio listen only access for other members of the community that want to attend but aren't part of core.
* [ ] Marius - reach out to internal IT to clean up some Zoom hiccups.
* [ ] Marius: intel compiler architecture repo update.