# Package maintenance policies **URL:** \ **Category:** Community\ **Created:** [February 5, 2023, 4:22am UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337 "2023-02-05T04:22:40Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![jbeckford](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jbeckford/32/3027_2.png) [@jbeckford](https://discuss.ocaml.org/u/jbeckford)\ **Post date:** [February 5, 2023, 4:22am UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/1 "2023-02-05T04:22:40Z")
I think there is a specific question in there. Can we have a known-in-advance agreement that if you submit a package to the central opam repository, that someone else may release new package versions under certain conditions: - It has been six (?) months without progress on any PRs of any kind, or - It has been six months without acceptance of a “compatibility” PR (OCaml 5, Windows, etc.) that is critical for OCaml forward progress, or - 7 days without response if it is a critical security vulnerability - AND any forked code is compatible (same or more liberal) with the original maintainer’s license - AND original maintainer and dates are part of the package description Something like that. Basically just solidifying that opam repository must stay high quality (which requires forward progress). ---
**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\ **Post date:** [February 5, 2023, 4:32am UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/2 "2023-02-05T04:32:28Z")
That’s a good idea, and the opam registry maintainers have the right to ask for agreement on terms like these before accepting the package into the registry. A bot could be set up to enforce the agreement. In retrospect it would have been good to do it from the beginning, but of course hindsight is 20/20. Another example is the PyPI maintainers asking publishers of critical packages to take extra security steps like using 2FA logins. ---
**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\ **Post date:** [February 5, 2023, 6:23pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/3 "2023-02-05T18:23:09Z")
My suggestion some time ago as an acceptable workaround for this was to introduce the concept of namespacing, like npm does. So you could have `aantron/dream` and then fork it as `ocaml-community/dream`. Needless to say, there was pushback on that. ---
**Author:** ![fermin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/fermin/32/3423_2.png) [@fermin](https://discuss.ocaml.org/u/fermin)\ **Post date:** [February 5, 2023, 6:45pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/4 "2023-02-05T18:45:31Z")
> [@The future of Dream](https://discuss.ocaml.org/t/the-future-of-dream/10602/15): > > Should OCaml have a plan for if a package maintainer disappears or becomes unable to work anymore? FWIW, here’s how the Haskell folks do it: [Taking over a package - HaskellWiki](https://wiki.haskell.org/Taking_over_a_package) ---
**Author:** ![edwin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/edwin/32/627_2.png) [@edwin](https://discuss.ocaml.org/u/edwin)\ **Post date:** [February 6, 2023, 12:10am UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/5 "2023-02-06T00:10:28Z")
> [@jbeckford](#): > > 7 days without response if it is a critical security vulnerability If the package has a published security policy saying that, sure. Might need a few safeguards, e.g. person who opened the security issue can’t be the person requesting to take over the package maintainership. (think about someone from outside the usual OCaml community trying to subtly insert malware by first reporting some security issues, pretending to fix them by taking over the package and later silently start inserting some malware, especially if it is a popular package used by many). Not to mention that if a package author goes on a vacation, coming back and finding all your packages suddenly taken over may not be what you expect. > [@jbeckford](#): > > - It has been six months without acceptance of a “compatibility” PR (OCaml 5, Windows, etc.) that is critical for OCaml forward progress, or > - 7 days without response if it is a critical security vulnerability I think I’ve seen ‘opam’ add ‘patches’ in these situations (well certainly in the first, to fix build issues), and that is quite usual for Linux distributions to do as well. ‘opam package maintainer’ doesn’t necessarily have to be equal to ‘upstream author’, and for small changes the ‘opam repository maintainers’ may be a “maintainer of last resort”. Having said that after a prolonged absence of the upstream author(s), a place to collaborate and evolve the package may be desired, in which case a name change may be the easiest solution, and there is precedent in the ‘opam repository’ for that already. E.g. [cil 1.7.3 · OCaml Package](https://ocaml.org/p/cil/1.7.3) which doesn’t work with OCaml 4.06+ and upstream hasn’t been active on the git repo since 2013, and [goblint-cil 2.0.1 · OCaml Package](https://ocaml.org/p/goblint-cil/2.0.1) which is a fork that does work with newer OCaml versions and has an active upstream. It is also fairly obvious to find the second one if you search for it since it does include the original package in the description. > [@jbeckford](#): > > someone else may release new package versions ‘opam’ has a feature to print ‘messages:’ or ‘post-messages:’. Perhaps it could be a two phase process: - once ocaml-community/ has been created and submitted add a ‘messages:’ or ‘post-messages:’ to the last version of origin in opam to print something like: ‘package maintainership is being transferred to \, install if you want to use the new version. On new releases of will come from \’. - keep unchanged other than the ‘messages’ entry, and publish a new ‘’. Downstreams can update their dependencies to use the new package if they wish or wait until . - if maintainer comes back before then transfer is cancelled, and as in the Haskell process there should be a way to transfer the package back to original maintainer even after a longer time should they want to. If a package maintainer wants to orphan their packages sooner than that they can use the existing process: [opam-repository/CONTRIBUTING.md at master · ocaml/opam-repository · GitHub](https://github.com/ocaml/opam-repository/blob/master/CONTRIBUTING.md#adopting-and-relinquishing-package-maintainership) ---
**Author:** ![Gopiandcode](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/gopiandcode/32/5346_2.png) [@Gopiandcode](https://discuss.ocaml.org/u/Gopiandcode)\ **Post date:** [February 6, 2023, 6:13am UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/6 "2023-02-06T06:13:37Z")
> [@The future of Dream](https://discuss.ocaml.org/t/the-future-of-dream/10602/21): > > Not to mention that if a package author goes on a vacation, coming back and finding all your packages suddenly taken over may not be what you expect. Yes, agreed. It may be a misinterpretation of the intent of @jbeckford’s phrasing, but I feel that the proposed suggestion leans too far on a guilty until proven innocent approach to package maintenance, where the control of one’s package can be wrestled away by a motivated party. > [@jbeckford](#): > > AND any forked code is compatible (same or more liberal) with the original maintainer’s license This is likely a problematic clause, because many licenses explicitly _don’t_ allow such relicensing without the author’s permission. The OCaml community is already quite small (smaller than Haskell’s at least), and so I feel like such an adversarial approach to package management is more harmful to the ecosystem than beneficial. Why can’t we just adopt Haskell’s policies verbatim? It works for them, and I’d guess there’s likely a significant overlap in goals and attitudes of both communities. ---
**Author:** ![jbeckford](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jbeckford/32/3027_2.png) [@jbeckford](https://discuss.ocaml.org/u/jbeckford)\ **Post date:** [February 6, 2023, 8:43am UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/7 "2023-02-06T08:43:41Z")
> [@The future of Dream](https://discuss.ocaml.org/t/the-future-of-dream/10602/22): > > Why can’t we just adopt Haskell’s policies verbatim? It works for them, and I’d guess there’s likely a significant overlap in goals and attitudes of both communities. For the record, I like the Haskell policy. Although I am puzzled why one would be concerned about the loss of control after 6 months of being unresponsive (which is what I suggested to kick off the conversation) versus a 2-6 week period (the Haskell policy). > [@edwin](#): > > Might need a few safeguards, e.g. person who opened the security issue can’t be the person requesting to take over the package maintainership. Yeah, I am emphatically not suggesting a take over for a security patch. Instead: a small but reasonable time window for a `.patch` in the opam metadata to address that one critical security vulnerability, especially if that person is on vacation and (wisely!) did not take their laptop. I think this situation is much rarer than the unresponsive maintainer, and may not need to be addressed in a first pass. But your safeguard is a great idea. * * * At a high level, I don’t think this is a great forum to go over fine details. The owners of opam can decide if they want something like an explicit agreement or not. Just want to socialize the idea that package maintainers (including me) may find it beneficial to give up some rights when we submit packages to opam so we maintain a top selling “feature” of the OCaml ecosystem … the high quality opam repository that we have today. ---
**Author:** ![mro](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/mro/32/2496_2.png) [@mro](https://discuss.ocaml.org/u/mro)\ **Post date:** [February 6, 2023, 12:07pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/8 "2023-02-06T12:07:51Z")
What are expectations of package consumers? And what guarantees does the package repository want to provide? Personally, I only care about discoverability, the rest is IMO task of the package maintainer. And mine as a package consumer to choose my dependencies wisely. ---
**Author:** ![cemerick](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/cemerick/32/1383_2.png) [@cemerick](https://discuss.ocaml.org/u/cemerick)\ **Post date:** [February 6, 2023, 3:50pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/9 "2023-02-06T15:50:22Z")
It seems to me that developing code/package quality metrics (like “days since last PR accepted”, etc) is difficult even in private, closely-held organizations; doing the same in a community space like this feels extremely challenging, with potential side effects that might not be easy to predict ahead of time. (Are there any examples of other language communities having such standards for their package repositories? If not, I think that that’s probably not coincidental.) One of the main weaknesses of opam’s model is showing here; since there’s no namespacing/scoping (as found with e.g. maven, and optionally in npm), package names become precious commodities. (Hackage has a policy here because it has the same problem.) It’d be great if multiple parties could concurrently publish packages of the “same” name under different team/group/scope umbrellas; in spaces where this is possible, it can pretty quickly help establish a consensus when a fork is necessary (whether due to maintainer departure, or simply disagreement about project direction), without having to develop and agree on “quality metrics” or any other sort of package control policy ahead of time. _(Ech, somehow noticed only after the fact that @yawaramin mentioned this whole topic [upthread already](https://discuss.ocaml.org/t/package-maintenance-policies/11337/3), mea culpa)_ ---
**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\ **Post date:** [February 6, 2023, 3:58pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/10 "2023-02-06T15:58:10Z")
Feels like I’m not shouting into the void any more! ---
**Author:** ![cemerick](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/cemerick/32/1383_2.png) [@cemerick](https://discuss.ocaml.org/u/cemerick)\ **Post date:** [February 6, 2023, 4:02pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/11 "2023-02-06T16:02:10Z")
I mean, maybe, maybe not; just because there are two people and not one, does not mean they’re not still surrounded by a void 😉 > [@yawaramin](#): > > Needless to say, there was pushback on that. I’ve looked previously for opam issues related to this, but have come up empty-handed. Did I miss it/them? ---
**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\ **Post date:** [February 6, 2023, 4:52pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/12 "2023-02-06T16:52:40Z")
In retrospect, I guess not so much ‘pushback’ as ‘lack of interest’: [Proposal: opam namespace (scope) for self-published packages](https://discuss.ocaml.org/t/proposal-opam-namespace-scope-for-self-published-packages/6404) ---
**Author:** ![jbeckford](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jbeckford/32/3027_2.png) [@jbeckford](https://discuss.ocaml.org/u/jbeckford)\ **Post date:** [February 6, 2023, 8:16pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/13 "2023-02-06T20:16:29Z")
That is an interesting proposal @yawaramin . I’ll admit before I read it I was worried that namespacing _could_ destroy the hand-curation of opam repositories that IMHO (repeating myself) is one of the strongest features of the OCaml ecosystem. I saw that concern echoed in that thread, and your initial phrasing of “pushback” seems accurate. But nothing precludes a good namespacing design from overcoming that obstacle, right? I for one would like to see a more concrete proposal for namespacing. * * * The other proposal in this thread is mine. But since I see a few strawmen arguments being waved around, I am going to remove the ambiguity: - There is no “take over” in the proposal. In fact, those words do not appear in my proposal. And even in the [Taking over a package - Haskell policy](https://discuss.ocaml.org/t/package-maintenance-policies/11337/4) they are very clear to end it with: - I mentioned as the first item (unfortunately in retrospective!) including six months of without progress on any PRs _of any kind_. Somehow that morphed into developing code/package quality metrics. No. If a few people have submitted PRs and issues, and the maintainer hasn’t responded with a simple “hi!” to _any of them_, then you can assume after six months that they are incapacitated. This is actually common, and I thought it would be the least controversial so I incorrectly listed it first. Completely wrong! Let’s get rid of that item. - My proposal was in direct response to the following situation (stripping out names and products to de-personalize it): ---
**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\ **Post date:** [February 6, 2023, 9:04pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/14 "2023-02-06T21:04:32Z")
> [@jbeckford](#): > > But nothing precludes a good namespacing design from overcoming that obstacle, right? I agree, which is why I proposed that releases of namespaced packages need not be approved by a human, only releases of ‘global’ packages need be. Effectively, leaving the existing workflow as is, and adding on a new workflow layer on top of it. I’ll also add that `opam-repository` is a fairly complex GitHub project that is being maintained by humans right now. Of course they are doing a fantastic job. But it is still a menial job, which is taking up the time and energy of these humans, and having to deal with the constant stream of breakages and fixes must surely be a pretty big job. Many parts of which could be automated. My proposal is just one of many possible ways to do it. ---
**Author:** ![AltGr](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/altgr/32/4220_2.png) [@AltGr](https://discuss.ocaml.org/u/AltGr)\ **Post date:** [February 10, 2023, 3:49pm UTC](https://discuss.ocaml.org/t/package-maintenance-policies/11337/15 "2023-02-10T15:49:22Z")
Just adding two grains of salt: - it’s possible (although a bit cumbersome to repo maintainers) to add patches directly in opam-repository against the upstream for critical fixes when you can’t wait for the owner of that upstream to respond - you may be interested in [Conex](https://github.com/hannesm/conex), which unfortunately hasn’t yet been integrated into opam, but has some provisions to manage such cases (once you switch to end-to-end package signatures, package takeover would become impossible without those)