[Caml-list] Proposed Package Archiving Policy for the opam Repository

[Caml-list] Proposed Package Archiving Policy for the opam Repository

[Hannes Mehnert]

Dear everyone,

please find below an announcement for the archiving policy of the opam 
repository - together with a call-to-action, and a roadmap.

NB: there is an online rendered version at 
https://discuss.ocaml.org/t/proposed-package-archiving-policy-for-the-opam-repository 
- best to discuss this there as well.

## 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](https://github.com/ocurrent/opam-repo-ci/blob/master/doc/platforms.md).

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](https://github.com/hannesm) requested comments on 
a [proposed 
initiative](https://github.com/ocaml/opam-repository/issues/23789) 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](https://github.com/ocaml/opam-repository/issues/23789), 
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](https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md).

The currently empty [repository 
archive](https://github.com/ocaml/opam-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](https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process).

## 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](https://discuss.ocaml.org/tag/opam-repository).

* 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

* [Opam repository 
archive](https://github.com/ocaml/opam-repository-archive)
* [Proposed 
policy](https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md)
* [Plan of 
action](https://github.com/ocaml/opam-repository/wiki/Package-Archiving:-Plan)
* [Issue and 
discussion](https://github.com/ocaml/opam-repository/issues/23789)
* [Previous 
announcement](https://discuss.ocaml.org/t/discussions-on-the-future-of-the-opam-repository/13898)

## 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


Best,

the opam-repository maintainers team