Dear everyone,
it is my please to announce the proposed package archiving policy in the name of the opam-repository maintainers.
Context
The opam repository differs from nearly all other programming-language-centric package repositories in that it is manually curated by volunteer maintainers and protected by a robust continuous integration system that (generally) ensures published packages work as expected across a large matrix of supported platforms.
Over the past few years the repository has kept growing steadily, when not accelerating, and this has started raising questions about the size, weight and sustainability of the repository and its processes. Last year, Hannes Mehnert requested comments on a proposed initiative to improve the sustainability and quality of the opam package repository on the long term.
Problem
The problem, in a nutshell, is that the opam-repository will keep steadily growing, using an increasing and substantial amount of space and inodes. Every opam user needs to invest a large amount of computational resources for the solver, every time they want to install or update a package. Additionally, a large amount of computational resources are spent in the continuous integration process and yet a lot of the packages have become stale or uninstallable.
Solution
After much deliberation, the discussion converged on a solution: introduce a package archiving policy and supporting processes, to periodically identify and prune unmaintained and broken packages from the repository. This will improve the performance of the opam solvers, of the opam-repo CI, and most importantly improve the quality of the package repository, while keeping a sort of immutability of the repository content and preserving the usability of historical packages for the users that want or need them.
The opam repository maintainers propose a policy.
The currently empty repository archive has been created, waiting for packages to be moved.
Call to action
If you maintain packages in the opam-repository, you can help by defining your maintanence intent: add a new field x-maintenance-intent to your opam file(s) (the most recent release of your package is sufficient - please also put this field in your git repository so it will be part of future releases). The value is defined in the policy.
Roadmap
All announcements will be on discuss.ocaml.org with the opam-repository tag. If you like to follow these announcements, keep your eyes at the opam-repository tag.
- December 1st 2024: announcement of this proposal
- December 15th 2024: announcement of the packages affected by Phase 1 (uninstallable packages (āavailable: falseā, āflags: avoid-versionā or ādeprecatedā, āopam admin check --installableā, does not compile ā opam health check https://check.ci.ocaml.org/)
- January 1st 2025: Phase 1 cutting point: packages are moved to opam-repository-archive
- January 15th 2025: announcement of the packages affected by Phase 2 (OCaml lower bound 4.08)
- February 1st 2025: Phase 2 cutting point: packages are moved to opam-repository-archive
- February 15th 2025: initial spring cleaning, announcement of packages (based on maintenance-intent)
- March 1st 2025: spring cleaning cutting point: packages are moved to opam-repository-archive
- Every quarter: repeat Phase 3
- Every year: reconsider Phase 2 with an increased OCaml lower bound
We now invite members of the OCaml community who may not follow the ocaml-repository issues to review our plans and submit comments, questions, or suggestions.
Thank you in advance for your support!
References
Acknowledgment
Thanks to the following individuals for valuable input and contributions to the planning process (sorry in case we forgot you):
- Marcello Seri
- Shon Feder
- Thomas Gazagnaire
- kit-ty-kate
- Weng Shiwei ēæ士ä¼
- Marcus Rohrmoser
- Reynir Bjƶrnsson
- Stephen Sherratt
- Simon Cruanes
- Marek Kubica
- Raphaƫl Proust
- Romain Beauxis
- Yawar Amin
- Anil Madhavapeddy
- Boning D.
- Mathieu Barbin
- Hannes Mehnert
.