conda-forge core meeting 2025-09-03

Add new agenda items under the Your __new__() agenda items heading

• Zoom link
• What time is the meeting in my time zone
• Previous meetings

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

• (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
• (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
• (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

• [ ]