Skip to content

Meeting notes

Jump to bottom
Marcello Seri edited this page May 29, 2025 · 88 revisions

Agenda for next meeting

Meeting notes

2025-05-29

  • present: Marcello, Ivan, Manas, Shubham, Mike, Chukwuma
  • Ivan: status of the ocaml-ci. We agree that removing the redundant check is ok, since in recent years it was only noticed in false positives
  • Ivan: CI issues with release of compiler packages. This is complex, brittle and rarely a real issue for us, so it is better probably to not do anything
  • shubham: documentation is in progress to understand reverse dependencies, the current draft is here
  • Action point: double check status for triaging org members, to add new members
  • parallel triaging. Discussion on common first release errors in https://github.com/ocaml/opam-repository/pull/27936
  • Ivan: freebsd failures. Opened an issue at https://github.com/ocurrent/opam-repo-ci/issues/437 but was fixed in the meantime, we will reopen it if needed (and on ocaml/infrastructure where it belongs)

2025-05-22

  • present: Jay, Andre, Ivan, Manas, Shubham, Mike, Chukwuma
  • Sharing updates about our research and work
  • Shubham:
    • I’ll work on the revdeps issue we’ve discussed with Shon in Discord
    • Ivan: If you need any help with this, feel free to ping core maintainers or any of us present on the meeting
  • Ivan:
    • Shared an update regarding triaged and merged PRs. Common problems: some can be addressed using “How to deal with the CI” wiki, and some (like flambda) is just happening and you need to know about them
    • Mike: I believe in two ways of work. Solo researching but also collaborating in groups. We can go over the opam-repo-ci to get a better understanding on how it works
    • Ivan: I can do that collaboration as well. Tomorrow or next week. We can pick the time that can work for everyone who wants to join
    • Chukwuma: I’d like to join as well
  • Mike:
    • There happened a small communication on opam-repo-ci#424 issue, I’m working on that
    • Ivan: No problem. Just leave a comment, so everyone knows about it
  • Jay:
    • I pre-triaged a few PRs. One had similar issue with flambda, and the other I helped to fix
  • Andre:
    • I was observing how people handle the PRs. I took #27877, saw the error and actually wanted to fix the thing as the error was very clear. Unfortunately, I did not have additional 30-40 minutes at the time though, so I ended up doing nothing. Yet I could’ve just looked at the CI like Marcello did and leave the comment with questions
    • Mike: Maintainers will probably know their package better than we do, so we can just flag an issue
    • Ivan: I think of us more like moderators of something. It’s not our role to fix things, we just need to point package publishers in the right direction and they can handle the rest
    • Andre: Yes, I just need to change a mindset a little bit
  • Jay:
    • Do we need to post a pre-triaged PRs to the Discord?
    • Mike: I don’t think so. It’s good for our visibility but people will anyway saw comments on GitHub
    • Ivan: I do it because we can make the waiting time from the PR opening to merging much smaller. I think it’s a good experience for people who submit packages.

2025-05-14

  • present: Jay, Marcello, Raphael, Andre, Ivan, Manas, Make, Shon
  • We did another round of intros
  • overview on what we are usual doing during meetings.
    • Raphael:
      • Most work happens async
      • Strategic discussions
      • Sometimes we are triaging during the meetings, but it's not our primary effort.
    • Marcello:
      • Also good time for policy discussions
  • Manas:
    • Windows on the repo?
    • Raphael: we definitely need help with Windows on opam
    • Manas: I would like to really focus on Windows, and feel free to tag me!
    • Areas where Windows focused work can already be helpful:
      • Fixing packages that are marked as not available on Windows
      • Helping debug problems on Windows
      • Helping repair/develop CI
  • Mike:
    • What is the preferred communication if new maintainer?
    • If we think we have a good idea of what is needed on a PR, do just approve the PR?
    • Raphael:
      • You can remark that you have reviewed PRs in the comments and add your reviews.
      • Feedback on PRs for things to fix is very helpful.
      • Questions are welcome.
      • Questions on Discord also always welcome!

2025-05-08

  • present: @shonfeder @aguluman @Randy @mikejeuga @lubegasimon
  • Shon gave a tour of the repo. High level explanation of the subdirectories
  • Talked about ocaml/opam
  • Talked about dune-release & opam-publish
  • Looking at merging a PR (smtml )
    • What to do with specific permissions (merge vs triage)
  • How to look at specific tagged PR ?
  • Shon's view on how to look at PR to review
    • Merged smtml.0.7.0
    • We looked at a merge problem and went into digging the opam-ci break
    • Looked at how we can help out the publishing author.

2025-03-20

  • present: Shon, Marcello
  • Draft call for new maintainers https://hackmd.io/K3w5N9B-RBa2U3WIWqkbew#
    • Marcello is happy with it.
    • Next up: get Raphael's OK/input and then post
  • name squatting (e.g., for semgrep)
    • name-squatting with dummy packages is against or policies
    • we currently have no support for namespaces
    • the way to claim the name-space is to publish an alpha version

2025-02-06

  • present: Hannes, Raphael, Shon
  • Archiving effort (Hannes)
    • Phase 2
      • packages not supporting >= 4.08 are archived
      • packages not supporting >= 4.08.0 are to be archived
    • Turning now to incorporating x-maintenance-intent
      • The semantics here have been updated to mean "latest version that builds on all compilers supported by the primary repo"
        • Shon: I find this extremely confusing frm a package author's intent
        • Hannes: the aim is to ensure we don't end up with an effectively empty packages repo on old supported versions of compiler.
        • Shon: Perhaps we should update policy to state that this is a property we want to maintain (i.e., keep working packages for supported versions even if they are older than the maintained version), rather than stating this as part of the

2025-01-30

  • present: Hannes, Raphael, Shon
  • Archiving effort
    • phase 2 starting on saturday
      • No concerns have been raised about moving the supported compiler version to 4.08
      • This will be merged on Saturday!
    • Planning to start working on algorithm for removing files for next phase
      • Will be experimenting with x-maintenance-intent parsing library.
  • How to deal with raising concerns about processes as they arise? (E.g., with the archiving effort and processes.)
    • Discord is not a good medium for having ongoing discussion about more nuanced stuff.
      • But when we do use it, being sure to provide cross-references and context would be helpful.
    • A document with open questions and concerns as they arise would be useful.
      • We will keep such a document in the wiki to record the considerations
  • Call for new maintainers
    • Shon to draft a call for new maintainers, we can discuss where all to share it next week.

2025-01-16

  • short demo of code for intent matching (git repo incoming)
  • intent field discussion
    • we need x-maintained boolean field which applies to a single version of a package and overwrites maintenance-intent
    • what default should we have for maintenance intent:
      • any? that's the current behaviour, we should have that as default for now and switch to a different one later
      • latest?
      • latest for each ocaml version? (latest compatible with 4.08, latest for 4.09, etc.) possibly a simpler thing is to say that intents (default or otherwise) apply to each version of ocaml separately, we probably don't want to deal with OSes and other "platform"/"system" compatibility
  • survey of current uses of x-maintenance-intent 
   2  [ "(latest)"  "(latest-1)"  "(latest-2)"  "(latest-3)"  "(latest-4)" ]
   1  [ "(latest)" "(latest-1)" ]
   6  [ "(latest)" "(latest)-414" ]
 128  [ "(latest)" ]
   3  [ "(none)" ]
   1  ["(any).(any).(latest)"]
 105  ["(latest)"]
   6  [("latest")]
   1  "(latest)"

2025-01-09

  • present: Kate, Hannes, Raphael, Marcello
  • ocaml-community/meta: new "lax" opam repo
    • https://github.com/ocaml-community/meta/issues/45
    • most maintainers are not worried, thinks this could be a good place for experimentation
    • Shon is worried: thinks it may cause fragmentation of the ecosystem, thinks it would be much more helpful for those interested to participate in opam repo maintenance
    • motivated by the number of open PRs in part?
  • discuss x-maintenance-intent syntax
  • discuss the use of flags: deprecated
    • Kate: seems to overlap with maintenance intent. So what is the need for deprecated flag if we already have
    • Shon: my expectation is that "deprecated" packages may be maintained, but it is a notice that it will be going away.
    • Hannes: Previously discussed that deprecated discussed as a way to help guide archiving of specific older packages
  • call for more opam-repository maintainers?
  • new meeting time
    • 15CET

2024-12-19

  • Archiving project
    • Phase 1
      • Confirming plans to execute archiving on January 1
        • Is gpatch problem still an issue on MacOS
          • Creates problems when MacOS when files are deleted
          • Thanks to updates to opam distribution on macos we don't anticipate this being a problem for many
          • But we will put info on this into the FAQ
      • CI work for archiving policy
    • Phase 2
    • should compilers < 4.08 be archived
      • No, we think they should stay in the primary repo
      • TODO: update policy with exception for compiler
      • But Hannes will add post install message for packages < 4.08, noting that packages for this opam compiler will not be available
    • Phase 3
      • We will need some CI logic to validate packages eligible for removal (e.g., that they do not break reverse dependencies)
        • Will we need opam.ci logic for revdep testing revdeps or packages to be removed
      • Centralized opam source cache as fallback could avoid us having to deal with future unavailable packages
  • Holidays!
    • Many people out, so no meeting until Jan. 6th.

2024-12-12

present: @hannesm, @kit-ty-kate, @mseri, @raphael-p

  • Archival of available:false. All ready for announcement
  • Tool to ping people of removed packages (not needed for phase 1) in progress by HAnnes
  • Opam admin check needs to run -i, so what is currently in the PR comment is too much, but anyways this is postponed to next phase
  • Discussed https://github.com/dra27/opam-repository/pull/20/files, we agree on merging it when the time comes since it improves the state of things. It is a bit confusing and it would be nice to have a streamlined default for availability. Marcello think that just using the available field is easier, but this is in any case something for later. The lint discussion is separate and should not affect that PR.
  • Discussed https://github.com/dra27/opam-repository/pull/21/files. It is there to break a chain of dependency between oca-base-compiler and ocaml-variants, but we should avoid surprises (modifying the installed compiler with extra flags unadvisedly) and this PR makes sure of it.
  • We should discuss what we should do for deprecated and avoid-version packages. Idea: move deprecated and alpha/beta/rc of opam and ocaml at phase 2, check with maintainers of avoid-version to mark them deprecated where possible (caveat: not make deprecated an avoid-version which has not yet a newer release).
  • Tricky: opam admin check -i (see https://github.com/ocaml/opam/pull/6335) should make sure that we are not making maintained packages uninstallable, but we may look into something manual that also checks the test and doc dependencies. We will explore both a new tool or relying on old ideas (https://github.com/ocaml-opam/Camelus/blob/c5a4511cfab48aece11a3f7229e23d4eccde7dc6/camelus_lib.ml#L962-L1020) or opam and see what works better.

2024-11-28

present: @shonfeder, @hannesm, @mseri

  • Reviewing Hannes' work on the archiving initiative
    • Draft of announcement
    • PR for archive repo https://github.com/ocaml/opam-repository-archive/pull/1/files#
    • We all agreed that the current inclusion criteria IDs are a bit confusing in the context of an archived package's x-reason-for-archival field.
      • We will move the policy documents into the repo, and fix this via a followup PR
      • We agreed there are other benefits to moving the policy documents into the repo:
        • Policy is visible when repo is checked out
        • Changes to policy are more visible to opam users
        • We can suggest and manage changes via PRs
  • @shonfeder: enabling branch protections could have helped prevent the breakage in https://github.com/ocaml/opam-repository/issues/26956
    • @mseri: would be OK with enabling branch protections if we can do it in a way that is not too invasive and doesn't block cases when we do want to bypass some CI failures

2024-11-21

present: @shonfeder, @hannesm, @mseri

  • Archiving policy
    • Hannes (via Robur) will take a on a contract to champion the archiving policy
    • value of notice-weeks in archiving policy: 2
    • Next step:
      • @mseri will contact Gabriel and get the paperwork working
      • Hannes:
        • extend draft of announcement with list of initial archival candidates
        • contact Anil to ask about creating the new
  • Policy discussion around policy and CI change management: https://gist.github.com/shonfeder/204d564cf246190368481ae5ee997dbd
    • Lints for pre-releases: https://github.com/ocurrent/opam-repo-ci/issues/385
    • Marcello:
      • it is enough to ensure that all active maintainers formed consensus
    • Process:
      • Discuss in maintainer meeting
      • Record decision in notes meeting notes
      • Changes
        • Policy changes will have an issue on opam-repository
          • Then manifest in changes in the wiki
        • CI changes will have an issue in opam-repo-ci
          • Then manifest in changes a PR
    • Next steps:
      • Shon to record in wiki
  • octez and policy for very large release groups
  • macos issues with homebrew
  • improving fault tolerance of CI runs

2024-11-14

present: @raphael-proust, @shonfeder

  • Discussing agenda for OCSF meeting

2024-11-07

present: @shonfeder, @mesri

  • Draft for archiving policy draft due for comments

2024-10-31

present: @shonfeder, @mesri

  • Archive policy
    • Shon will allocate time to helping move this forward
    • Next steps:
      • move policy and plan into wiki
      • draft announcement for discuss
  • Policy discussion around https://github.com/ocaml/opam-repository/pull/24267 how to move this forward
    • Proposed policy: opam only accepts packages which respect the sandbox
  • How to keep PRs from getting stale?
    • We have quite a few packages that are important and useful for the repo to land, but the person who opened the PR may not have the time to see the PR to total completion, e.g., https://github.com/ocaml/opam-repository/pull/25889
    • In the past we had a "Stalebot", but we would need to keep re-opening these PRs it closed.
    • What we think we need is a dedicated worker who can carve out dedicated time time to move these tricky packages thru.
    • Often what we are encountering in these cases are limits of opam's current packaging abilities: e.g., trying to install LLVM deps or C deps.
    • In such cases, it is valuable for the ecosystem for us to figure out how to extend opam's support.
  • Email addresses for maintainers: https://github.com/ocaml/infrastructure/issues/152

2024-09-18

Present: @raphael-proust, @shonfeder

We discussed some policy stuff, and have agenda items for next meeting.

2024-07-10

Present: @raphael-proust, @shonfeder, @mseri

2024-07-03

Present: @raphael-proust, @shonfeder, @mseri

  • Reviewing PRs, merging, etc.
  • Archiving of stale packages
    • discussed next steps
    • setting up a meeting for next week with infrastructure people to set up basics

2024-06-19

Present: @raphael-proust, @shonfeder

2024-06-12

Present: @kit-ty-kate, @raphael-proust

2024-05-29

Present: @kit-ty-kate, @raphael-proust, @shonfeder, @mseri

  • https://github.com/ocaml/opam-repository/pull/26003 : discussing what to do, maybe we should move it to the archive-only, opened wikipage "Known stale package" to keep track
  • Discussed the distro list for the CI. We should be able to remove old-ish Debian 10. Question is open for Debian 11 (still within LTS range).
  • Discussed the possibility of automatically accepting some PRs: what critera? what changes to the CI? what policies? what exceptions?

2024-05-29

Present: @kit-ty-kate, @raphael-proust, @shonfeder, @hannesm, @mseri

2024-05-22

Present: @kit-ty-kate, @raphael-proust, @shonfeder, @hannesm

  • Discussed #25876 - moving away from weak hash algorithms, moving forward with implementation (@hannesm) and PRs (reviews when the time come).
  • Agreed to reserve prefixes mentioned last week.
    • Mention of the relation to the need for namespacing.
    • Mention of the need for a lint check/warning.

2024-05-15

Present: @kit-ty-kate, @raphael-proust, @mseri, @shonfeder, @dra27

2024-03-13

Present: @kit-ty-kate, @raphael-proust

2024-03-06

Present: @kit-ty-kate, @raphael-proust

Work on draft of archival-repository proposal

2024-03-04

Meeting notes of the fourth public meeting on the future of opam-repository

2024-02-28

Present: @kit-ty-kate, @raphael-proust, @mseri

Triage and merging of PRs.

2024-02-21

Meeting notes of the third public meeting on the future of opam-repository

2024-02-14

Present: @kit-ty-kate, @arbipher

No active maintainers with commit rights was present so instead Kate tried to teach how to review PRs. In doing that:

  • the main wiki page was updated
  • the review guideline page was updated to the new documentation (there are still some TODO but it's good enough and is up-to-date)
    • notes about constraint equality and dune subst was added
  • a note about how to create code suggestions (github feature) was added to the onboarding documentation

2024-02-07

Meeting notes of the second public meeting on the future of opam-repository

2024-01-31

  • Discussed afl-persistent issues on macos. Pinged developer. Made a PR to opam-repo to add a patch.
  • Discussed lru-cache/lru_cache name collision. Ran local tests. Opened issue on opam-repo-CI. https://github.com/ocurrent/opam-repo-ci/issues/264
  • Discussed next-week's meeting to prepare discussions.

2024-01-24

Meeting notes of the first public meeting on the future of opam-repository

2024-01-17

Notes to be written down later. Note taker got sick

2024/01/10

Present: @kit-ty-kate, @mseri, @arbipher

  • We would like to take action on the opam-repository scallability discussion and have invited people interested in the topic for a video chat
  • Discussed a bit about why OPAMCRITERIA* are changed in opam-repo-ci: it is needed for checking the lower-bounds constraints and is a remanent of the code otherwise
  • Discussed a bit of the reason why dune isn’t installed by default in the ocaml/opam images: dune is not a mendatory dependency, many packages do not depend on it at all and we want to check that the list of dependencies each packages lists is accurate and does not use dune without requiring it
  • Cleaned-up all the ready for merge PRs

2023/12/13

2023/12/06

Present: @kit-ty-kate, @mseri, @arbipher

2023/11/29

Present: @kit-ty-kate, @haochenx, @mseri, @arbipher

  • Discussed the idea of a set-date open meeting for opam-repository to try and get people interested in contributing
  • #24841: the patch itself is fine but it looks like a bug in ocamlfind (reported upstream in ocaml/ocamlfind#70)
  • opam 2.2.0~alpha brings opam admin add-constraint --packages=<PACKAGES> which only updates the listed packages. It was used for #24868
  • Discussed ocaml/dune#9272: the issue only appears when a package or dependency uses dune-site and promotion at the same time so it’s a bit too specific to do anything in opam-repository as it would mean people who are not in this case would be forced to downgrade dune-site or break their local project.

2023/11/22

Present: @kit-ty-kate, @arbipher, @mseri

2023/11/15

Present: @kit-ty-kate, @raphael-proust, @mseri, @arbipher

  • Issue triage.
  • There are linking issues appearing only in revdeps because in linux the linking is too permissive: it doesn't check that all symbols are defined. E.g., https://github.com/ocaml/opam-repository/pull/24745#issuecomment-1809744599 . No action required, but maintainers need to be aware.
  • Discussed removal of base-unix which seem to have no purpose. No action decided yet. We will revisit the question later.

2023/11/08

Present: @kit-ty-kate, @raphael-proust, @mseri, @arbipher

2023/11/01

Meeting cancelled

2023/10/25

Present: @kit-ty-kate, @haochenx, @raphael-proust, @mseri

  • Discussed @kit-ty-kate's draft documentation for the PR review guidelines.
  • Discussed #24652
    • The purpose of the conf-python-3 (version 9.0.0) is not fulfill as the original author thought that conf-python-3.9.0.0 meant the conf-python at the version 3.9.0.0 However the package is currently not used in this way. There should be a separate conf-python-3-9 if absolutely necessary. But mostly to fix this issue properly, opam needs to improve its support of depexts, in particular being able to have version requirements of depexts. See https://github.com/ocaml/opam/issues/2168

2023/10/18

Present: @kit-ty-kate, @haochenx, @raphael-proust, @rikusilvola, @mseri, @arbipher

  • Discussed @kit-ty-kate's draft of triaging guidelines. They are now on the wiki.
  • We need an "inbox" channel on public platforms for people to ask questions and to notify us about upcoming releases.

2023/09/20

Present: @kit-ty-kate, @haochenx, @raphael-proust, @rikusilvola

2023/09/13

Missing notes

2023/09/06

Missing notes

2023/08/30

Missing notes

2023/08/23

Missing notes

2023/08/16

Missing notes

2023/08/09

Present: @kit-ty-kate, @haochenx

  • None of the newcomers actually had triaging rights on the repository... wtf! (now fixed for haochenx)
  • General feedback from newcomer into opam-repository maintenance (haochenx):
    • It is unclear what to do as a new maintainer in the general sense in a lot of typical situations. For example the expectation communicated during the onboarding meeting was unclear about what to do in the situation when the newest PRs are already be triaged by someone else (especially what is expected for the new comers so our efforts may provide values for the reporters and other maintainers)
      • Actionable: Write a new maintainer's guide
    • It would be nice to have feedback as new maintainer
      • kit-ty-kate hasn't personally seen any of the new maintainers in the past month, apart from haochenx
      • can definitely give feedback when i see an action that doesn't go in the right direction but weekly meeting is more suited for more general feedback and progress tracking
    • Idea: show diff with previous version of the new package(s) using a Github Action
    • It would be nice to have a status.ci.ocaml.org website
      • Have a periodic health job on each server and disable that server if there is a problem
      • Actionable: pass that request to the CI team

2023/08/08

Present: @kit-ty-kate, @raphael-proust, @mseri

2023/08/02

Present: @kit-ty-kate

  • Cancelled due to lack of person present
Clone this wiki locally