Skip to content

Meeting notes

Jump to bottom
Raphaël Proust edited this page Jan 24, 2025 · 75 revisions

Agenda:

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
    • motivated by https://github.com/ocaml/opam-repository/pull/26890
    • policy:
      • We request that very large package releases proceed by first by releasing base packages
      • We request removal of non-useful packages (e.g., example packages)
    • Next steps:
      • Marcello to comment on PR
  • 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
    • Marcello: this is too strict currently.
    • Let's relax this. New requirements: must have an issue tracker, or else an email
    • Next steps:

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

  • We discussed PR https://github.com/ocaml/opam-repository/pull/24642 and what to do with archives that have disappeared. However the packages of this MR cannot be built on the current CI because of dated packaging. We replaced this PR by one that marks packages as unavailable.

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