Skip to main content

conda-forge core meeting 2025-01-22

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

Attendees

NameInitialsGitHub IDAffiliation
Wolf VollprechtWVwolfvprefix.dev
Klaus ZimmermannKZzklausQuansight
Uwe KornUKxhochyQuantCo
Jaime Rodríguez-GuerraJRGjaimergpQuansight
Matthew R. BeckerMRBbeckermrcf
Marius van NiekerkMvNmariusvniekerkcf

6 people total

Standing items

  • [ ]

From previous meeting(s)

  • [ ]

Active votes

  • [ ]

Your new() agenda items

  • (JRG) Move from Azure Pipelines to Github Actions to use osx-arm64 and linux-aarch64, runners, among other goodies.

    • Azure seems to be in feature freeze (this ticket was locked in April, this one got not answer) or very slow to roll out new features. It's been more than one year since GHA started supporting this arch, and almost a year since they became generally available.
    • There is one note about osx-arm64 in the Azure roadmap for 2025 Q2. "Working on a solution" for pricing. So not free? But no mention of Linux ARM.
    • Travis is not reliable enough to give us linux-aarch64 runners and Circle CI had trouble with new repo registrations.
    • If possible, I would suggest to transfer our conda-forge pool from one service to another. The pool must be separate from the normal GHA pool to avoid DoS'ing our own infra (rerender, lints and so on depend heavily on GHA workflows running on each feedstock). Who to reach out?
    • Any feedback? Is this workable or a terrible idea? Potential blockers?
    • Action items:
      • Jaime to draft email content in Zulip thread. Mention potential bump, and also the motivations for new runner types and attestations, access control, better ecosystem etc.
      • Wolf to find Codespaces contact
      • Someone with prior rapport to send email to Steve / GH support?
  • (IF) ABI3 status

  • (WV) recipe v1 on staged recipes by "default"

  • (WV) NumFOCUS SDG for package attestations with sigstore

    • WV: Here is a test repository that I am using for some testing of things on our end: https://github.com/wolfv/sigstore-test/actions/runs/12909555992
    • WV: You can find an attestation here: https://github.com/wolfv/sigstore-test/attestations/4571450
    • WV: You can search for a sha hash on sigstore.dev to find the artifact that was signed (this would work for the signed packages in conda-forge once we have that): https://search.sigstore.dev/?hash=7559cc269e98f41ca9e97ccbcfeadcecf177f2e2a744caf1f6e5b2604d8b5d43
    • Questions about how to make sure maintainers do not start randomly adding attestations of things that didn't make it to the production channel in conda-forge. Those extra attestation would add "noise" to the otherwise official way to check attestations in GH, so maybe we have to copy the "good attestations" to a service/storage we fully control. There were also arguments that the attestation itself tells you what package was built where, so as long as the users pay attention, there's no "noise".
    • Good moment to revisit OCI uploads and permissions along with this, since they seem similar in scope.

Pushed to next meeting

  • [ ]

CFEPs

  • [ ]