---
tags: [meeting-notes]
title: '2025-09-03'
---
# conda-forge core meeting 2025-09-03

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)
- [Previous meetings](https://conda-forge.org/community/minutes/)

## Attendees

| Name | Initials | GitHub ID | Affiliation |
| ----------------------- | -------- | --------------- | --------------------------- |
| Jaime Rodríguez-Guerra | JRG | jaimergp | Quansight/cf |
| Marius van Niekerk | MvN | mariusvniekerk | Inmarket/cf |
| Uwe Korn | UK | xhochy | QuantCo/cf |
| Isuru Fernando | IF | isuruf | Quansight/cf |
| Chris Burr | CB | chrisburr | cf |

5 people total

### Your __new__() agenda items

- [X] (UK) Merges on Python 3.14 PRs
- Policy for merge: immediately or deferred? Full week might be too slow for the migration to continue at scale
- JRG: Compromise with 48h?
- IF: Become a maintainer of the blocking feedstock if there's a rush. Otherwise might introduce extra efforts for the actual maintainers if something goes wrong.
- UK/MvN: Policy only for Python migrations.
- IF: Previous conversations proposed that the bot pings maintainers with certain notice (48h), but no one ended up writing the bot implementation. Maybe time to revisit.
- UK: Problems with failed rerenders often get in the way. Once fixed, what to do? Manual review to make sure CI matrix was actually updated?
- CB: Concerns about delays in delivering the Python update.
- IF: Within a month would be acceptable. Most feedstocks with thousands of children are maintainers by core people anyway.
- MvN: General approach in the past was to monitor the status progress updates and unblock major bottlenecks. That's where most of the "eagerness to merge" happens. Leaf nodes can progress in a slower way.
- UK: From a marketing perspective, leaf nodes are also important.
- IF: Leaf nodes are usually ok with a week of wait. The "rush issue" is mostly about packages with many descendents. Suggests to have a core person join the feedstock.
- UK: "Why pinging instead of just merge?" triggered this discussion.
- IF: Personal policy is to not merge without pinging, some others don't care that much.
- Conclusions:
- MvN: Find threshold for "graph criticality" of how many children is too many to "rush" a merge
- JRG: Encode guidelines in informative CFEP
- CB: having some metadata in the recipe for this at some point to communicate maintainer intent (e.g. core can merge any time, core can merge after a couple of days, core can merge after a week).
- Add `conda-forge.yml` file to staged-recipes example?
- JRG: Add message informing policy in PR migration description
- [X] (JRG) Relevant CEPs for conda-forge:
- CEP XXXX: Customizable system DLL linkage checks for windows #128: https://github.com/conda/ceps/pull/128
- CEP XXXX: Improving dependency export infrastructure #129: https://github.com/conda/ceps/pull/129
- [X] (JRG): Governance & emeritus members permissions:
- https://github.com/conda-forge/governance/pull/10
- https://github.com/conda-forge/conda-smithy/issues/2362
- MvN: Sounds sensible to generalize this to all subteams.

### Pushed to next meeting

- [ ] (WV): sigstore available in beta on prefix.dev
- [ ] (WV): would like to invoice NumFOCUS for the SDG, money went towards CEP-27
- [ ] (WV): unfortunately not much progress on signing for conda-forge just yet
- [ ] (WV): pixi build / build profiles discussion
- [ ] (WV): pixi-"conda" ideas (pixi without lockfile)

### CFEPs

- [ ]