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).
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.
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.
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.
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 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 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.
‘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 <ocaml-community/foo>, install if you want to use the new version. On new releases of will come from <ocaml-community/foo>’.
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.
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.
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.
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).
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.
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, mea culpa)
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 they are very clear to end it with:
If someone has their package taken over because they did not respond, then, for the following year, should they request it, the admins will unconditionally return it to them.
No one is taking your package away from you.
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):
I recently rewrote my XXX package so that it would not need YYY library: The reason for my change is that YYY does not support OCaml 5, even though the fix is not so difficult and [there is already] an outstanding PR for it.
So, I proposed a solution for compatibility situations that were critical (I enumerated them as “OCaml 5, Windows, etc.”). Sometimes these discussions devolve into theoretical tomorrow solutions, but the above example is a today problem. I have another example. I have a one year outstanding Windows PR where I was forced to a) fork with no reasonable path to merge and b) spend inordinate amount of still-ongoing time developing an alternative so Windows users don’t lose access to a large number of packages. I will make it into a happy ending (different discussion for later), but I want to emphasize that with Windows we’ve already been close to screwing over a large fraction of today’s new users. OCaml 5 is even more important; it has to succeed or we’ve just sleep-walked into a Python 2/3 split-brain scenario.
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.
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, 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)
