From 88203e4a9194d7f99d88c8d8ca9221c86589a7b6 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 23 Jan 2024 04:43:29 +0000 Subject: [PATCH 1/2] Add sphinx/src/orga/minutes/2024-01-24.md --- sphinx/src/orga/minutes/2024-01-24.md | 50 +++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 sphinx/src/orga/minutes/2024-01-24.md diff --git a/sphinx/src/orga/minutes/2024-01-24.md b/sphinx/src/orga/minutes/2024-01-24.md new file mode 100644 index 0000000000..94277d7b23 --- /dev/null +++ b/sphinx/src/orga/minutes/2024-01-24.md @@ -0,0 +1,50 @@ +--- +tags: [meeting-notes] +--- +# conda-forge core meeting 2024-01-24 + +Add new agenda items under the `Your __new__() agenda items` heading + +- [Zoom link](https://zoom.us/j/9138593505?pwd=SWh3dE1IK05LV01Qa0FJZ1ZpMzJLZz09) +- [What time is the meeting in my time zone](https://dateful.com/convert/utc?t=5pm) +- [Last week's meeting](https://hackmd.io/#REPLACE_ME#) + +## Attendees + +| Name | Initials | GitHub ID | Affiliation | +| ----------------------- | -------- | --------------- | --------------------------- | +| | | | | +| | | | | +| | | | | +| | | | | +| | | | | +| | | | | +| | | | | +| | | | | +| | | | | + +X people total + +### Standing items + +- [ ] + +### From previous meeting(s) + +- [ ] + +### Active votes + +- [ ] + +### Your __new__() agenda items + +- [ ] + +### Pushed to next meeting + +- [ ] + +### CFEPs + +- [ ] From 1f2d690b920417d93a99456cce16e9b33de2a2b5 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 24 Jan 2024 17:36:59 +0000 Subject: [PATCH 2/2] Update sphinx/src/orga/minutes/2024-01-24.md --- sphinx/src/orga/minutes/2024-01-24.md | 35 +++++++++++++++++++++------ 1 file changed, 27 insertions(+), 8 deletions(-) diff --git a/sphinx/src/orga/minutes/2024-01-24.md b/sphinx/src/orga/minutes/2024-01-24.md index 94277d7b23..fa0086dedb 100644 --- a/sphinx/src/orga/minutes/2024-01-24.md +++ b/sphinx/src/orga/minutes/2024-01-24.md @@ -13,17 +13,17 @@ Add new agenda items under the `Your __new__() agenda items` heading | Name | Initials | GitHub ID | Affiliation | | ----------------------- | -------- | --------------- | --------------------------- | -| | | | | -| | | | | -| | | | | -| | | | | +| Jaime Rodríguez-Guerra | JRG | jaimergp | Quansight/cf | +| Michael Sarahan | MCS | msarahan | NVIDIA/CF | +| Marius van Niekerk | MvN | mariusvniekerk | Voltron Data/CF | +| Cheng H. Lee | CHL | chenghlee | Anaconda/CF | | | | | | | | | | | | | | | | | | | | | | | | | | -X people total +12 people total ### Standing items @@ -37,9 +37,28 @@ X people total - [ ] -### Your __new__() agenda items - -- [ ] +### Your `__new__()` agenda items + +- [x] (HV) How do we introduce `{{ stdlib("c") }}`? + - Design [objections](https://github.com/conda/conda-build/issues/5053) were withdrawn, functionality is released in conda-build 3.28 already. + - Main question is how to roll out this change broadly. I suggest to keep it tightly scoped to just the C stdlib for now (though the possibility of linking it with a dedicated [migration](https://github.com/conda-forge/conda-forge.github.io/issues/2015) for `error_overlinking: true` remains an option, if we want). + - (IF) Think we should have a mini-migrator (piggyback) so we don't have to rebuild all C/C++ packages; only rebuild when we really have to. + - (MvN) Agrees that we should take a lazy approach to migration; maybe have a list of some packages to eagerly migrate + - (MvN/IF) We can safely assume that the "world is flat" -> dependent packages won't need to be migrated as well. +- [x] (HV) [Migrate](https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/5191) boost 1.84? + - Recently we've migrated every 4th release of boost; previously it happened more often (every second release). There was a suggestion by a core member (Uwe) to migrate for 1.84; I think it'd be worth doing. + - After the big refactor with 1.82 (splitting off header-only lib, adding run-export), it should be easier to migrate nowadays. + - (IF) We should collect/review data on how long it takes to perform a boost migration, and use that to judge how often we should update. e.g. if it takes 3 months, then maybe once a year is sensible; if it takes 1 month, then every six months? +- [x] (KE) Can we create an sccache store to reduce build redundancy? + - (MvN) Big question is, "where do we put the cache?" + - (MCS) Do we have contacts at MSFT or other cloud providers we can talk with? + - (MvN) `conda-build` behavior complicates caching; e.g., use of timestamps in build env names can leak into cache if not careful + - (IF) When do we need sccache? E.g., does building different build numbers vs [upstream] versions benefit from cache? + - (MCS/KE) Opinion at Nvidia is Rapids can't get on conda-forge because it would take too long to build. Exploring if sccache would make conda-forge distribution feasible. + - (IF) using Quansight-hosted builder may be an option + - (KK) Building all of Rapids likely a bigger job than PyTorch or TensorFlow. May also want to consider splitting into per-device architecture builds + - (MCS) Need clear motivation to distribute Rapids via c-f; don't want to overload c-f infrastructure otherwise + - (KK) Currently not possible to [easily] depend on cuDF, cuML ### Pushed to next meeting