2020-06-22 conda-forge core meeting
Attendees
- Eric D
- Filipe
- Uwe
- Jonathan Helmus
- Kirkham
- Matt B.
- Anthony Scopatz
- Lori
- Cheng Lee
- Ray Douglass
- Keith Kraus
- Sylvain
- Mike Sarahan
- Wolf
- Isuru
Agenda
Your agenda items
-
(anyone) intros for new people on the line?
-
(FF) NumFOCUS updates on GH 2FA, Google Drive, and AWS
- GitHub 2FA issue has been resolved (only needed for core members)
- Donors names and addresses are in NumFocus Google Drive
- Need to respond to NumFocus on possible AWS usage, deadline has passed. The purpose here was to get credits for CF to use on AWS
- Can send a note to Leah
- maybe get credits for AWS workspaces for windows machines? This would help with debugging windows stuff. Also have aarch64 machines. Edit the following doc if you've got ideas for how do to stuff with AWS. Next week Filipe will send an email to Leah / NumFocus
- https://hackmd.io/bXUZ8a08SBeTs4t9fVXR4A?edit
-
(FF) Scipy BoF, sprint, and members attendance/presentations.
- CJ/Marius will be handling packaging BoF.
- Anyone to handle sprints?
- Anyone submitting talks / tutorials?
- John to give talk on GPU packaging
- wolf giving talk on scikit-geometry
-
(CJ) standing budget item
- Waiting on follow up on existing AWS charges
-
(CJ/Anthony/MRB) making a conda-tools org for tooling (conda-smithy, conda, mamba, grayskull, boa, etc.)
- Bit of an existential threat of forking the community of conda package users. Would be good to try and avoid that.
- Centralize tools under one github org
- conda-forge org?
- benefit: already a NumFocus project. Get a lot of admin overhead for free (governance model, community participation, etc.)
- conda-tools or new other org?
- putting tooling org under conda-forge raises questions with some enterprise users and some other users. Separate org may be easier
- Form new org, apply as new NumFocus project. Accomplishes same goal of bringing together single set of community led tools and projects for this ecosystem.
- Proposal: If we form new org just copy the conda-forge governance model
- This could also be a good place to have the specification discussions that we've been talking about for a while (conda, conda-build meta.yaml, etc.)
- conda-forge org?
- (WV) Having specs in a centralized community-owned place would be
great - makes planning for the future feasible.
- (JH) there's a specs repo in the conda org, https://github.com/conda/schemas
- (FF) How do we avoid stifling innovation?
- pypa sort of has a "Graduate into top level org" policy.
- need to be a welcoming org. More along the lines of pyvis
- (SC) What is considered "core" to jupyter is not the implementations,
but the protocols / file formats / etc. If you write a tool in Jupyter
that supports these then you have immediate access to a wide variety
of tooling
- What is the analog of this for the conda ecosystem? package specs (meta.yaml), package formats, etc.?
- Need to be careful about naming. Don't want to become another "python packaging authority"
-
(WV) Quick announce of micromamba (https://gist.github.com/wolfv/fe1ea521979973ab1d016d95a589dcde)
-
(WV) Update on standardization of next gen package format from last meeting?
-
(MRB/Isuru) cos7 and CDTs plans
- merge this PR: https://github.com/conda/conda-build/pull/3969
- move all cos6/cos7 CDT packages from defaults to conda-forge
- update builds with
no_hoist
and run constrained on the sysroot packages - migrate all of them to new sysroot and add dep on sysroot package
- remove shims in compilers
-
(FF) Should we do Outreachy as part of an effort to support diversity in tech? Advantages are low cost and high impact. Dissdvantages are the time effort from the mentors.
-
(UK) CFEP-18: Packaging static libraries
-
(IF) cf-mark-broken: Marking not broken packages as broken
-
(KK) CUDA 11 support
- CUDA 11 dropped CentOS 6 support
- Ties into CentOS 7 migration above
cudatoolkit
11 - https://github.com/AnacondaRecipes/cudatoolkit-feedstock/pull/7