No you don’t. That’s not how it works at all. You just edit, try compiling ON YOUR OWN MACHINE, and see if it worked. The CI system just tells you if something fails on a new version of the compiler or what have you.
Anyway, I don’t think the ocaml-community github organization will be using a monorepo.
No you don’t. That’s not how it works at all. You just edit, try compiling ON YOUR OWN MACHINE, and see if it worked. The CI system just tells you if something fails on a new version of the compiler or what have you.
That will notify you when something break. But when you do want to upgrade the 100 packages, doing it package by package will be long and tedious.
Anyway, I don’t think the ocaml-community github organization will be using a monorepo.
Note that the method I describe doesn’t have to be done by the ocaml-community organization. Technically anyone can create it’s own duniverse tracking the various projects under ocaml-community. However, it seems to me that it would be in the interest of all maintainers to share and maintain such a repository in a central place.
In any case, duniverse or not I am personally looking forward to the ocaml-community organization. I have myself a few projects such as utop that I have been maintaining for about 10 years and are still used but I’m no longer interested in maintaining them on their own.
The hard and tedious bit is editing the code and making sure you have tests that cover the section of code you’re editing and making sure you didn’t break anything. A monorepo doesn’t help that.
Please feel free to move anything you like to ocaml-community, we’re very happy to host any such packages.
The hard and tedious bit is editing the code and making sure you have tests that cover the section of code you’re editing and making sure you didn’t break anything. A monorepo doesn’t help that.
A monorepo help you scale this process from 1 repository to 100 repository.
Please feel free to move anything you like to ocaml-community, we’re very happy to host any such packages.
Will do

Is there an issue with moving utop to ocaml? It seems like a fairly essential package that isn’t any less important than the other packages under ocaml/.
That would also be a fine thing in the case of utop given how many people use it. I suspect not every package is appropriate for the ocaml organization itself, but utop probably is. Of course, if utop becomes maintained by the ocaml organization, that raises the question of whether (someday) it should become the official top level.
My impression is that by putting it under the ocaml-community organization we don’t need to find a long term dedicated maintainer. Anyone can merge bugfixes, fix compatibility with new OCaml versions and do opam releases when necessary. For bigger development, we might still need one person to spend a bit more time on it to make sure the project stays consistent, but this could be a temporary maintainer. It’s a smaller commitment and in between the project stays alive. Overall this should provide a better QOS for users. In any case, I’m happy to explain the code I’ve written when needed.
We would still have to have some people who act as gatekeepers for code changes, but yes, it would mean that things like updates to new versions of OCaml would not need to only be one person’s responsibility.
I know it is not the main point of this thread, but I feel like it’s worth me trying to have a go at a second explanation of what the duniverse tool provides. This is based on my memory of a discussion with the tool’s authors a few weeks ago – so details and motivations may well be wrong, but hopefully the general idea will still be fairly accurate.
duniverse is basically a tool that takes a description of a set of inter-dependent projects and sets up a dune workspace containing all those projects as git subtrees. This allows you to conveniently build and edit those projects simultaneously, and even make git commits containing changes to multiple projects (which IIUC git will auto-magically turn into appropriate commits in the individual subtrees). This should make it much easier to coordinate changes across multiple dependent projects.
I think that the original idea was to use this to manage projects that want to vendor in their dependencies. From this perspective the whole combined workspace is your project and you commit it to your master branch. You can make edits to your dependencies, and easily submit them upstream, and since you’ve vendored the dependencies you can easily control which version of the dependency is used with your project.
Now, I’m a bit wary of vendoring – I think it is reasonable for an executable but a bit dubious for libraries – so I was initially a little sceptical. However, it was pointed out to me that this same tooling also supports another use case – which I shall dub “virtual monorepos” for lack of a better term. In this use case, the workspace created by duniverse is not commited as the source for your actual project – instead it is just your own little local monorepo with all the convenience benefits that provides.
No one needs to know that you are secretly using a monorepo workflow – duniverse just quietly sets one up for you and when you’re done helps you to submit your changes to the non-monorepo outside world. However, if you and your fellow collaborators are all working in very similar workspaces then you can also make a repo containing just the config files that tell duniverse how to set-up your workspace and anyone can just clone it, call duniverse and immediately have a convenient workspace for working on your projects.
I think this is all @jeremiedimino is really suggesting: adding a repo to the community organisation with the config files for a workspace containing all the projects under the organisation. For those who want to use it, it will give them a nice workflow for working on the community projects out-of-the-box.
Now, duniverse is, to my knowledge not actually released yet, and I worry that we’ve stolen some of @avsm’s thunder by discussing it publicly before he’s had a chance to do his big release/reveal. But I find myself quite excited by this project, and I didn’t want people to get the wrong idea about it before it was even released, so I thought I would post this anyway.
That sounds totally reasonable. I have no objections to it.
It’s a bit unfortunate that vendoring has a negative reputation. I think it’s a bit undeserved. Another way of looking at vendoring is simply as a way of supporting a lightweight forking workflow. As part of development, I find the ability to take some existing code and modify it to my liking to be essential. It’s not something that I do often, but it’s a life saver in some situations. These are the situations where I don’t have the luxury to get these changes into good shape, thoroughly test them, and work through upstreaming them. It’s a shame that I have to pay for this ability by creating conflicts with external libraries (renaming the vendors deps manually is extremely tedious), and hence making the publishing process more difficult.
Small reaction to that one: Packages should still have maintainers. “Community maintainship” in practice just means life support where nobody takes responsibilities for doing things. This is what happened for Lwt before @antron stepped up. If you want to resign and have someone else taking over, you should speak up explicitly and announce that.
I don’t want ocaml-community to become a landfill of deprecated, abandoned or neglected projects. The goal of ocaml-community should be to have a central host to easily make maintainers evolve and collaborate, not to avoid having them. We should seek to have either specific individuals or small groups of individuals (2 or 3) responsible for specific packages.
The manifesto already mentions that, but I believe we should make that clearer and also have a list of who is “head maintainer” of what.
I definitely do not see ocaml-community as a landfill. Moving utop to ocaml-community is simply my way of saying:
“I trust the community with commit rights on my project. If you find a problem that you know how to fix, please go ahead, update the code and make a new release. You do not need to wait for my approval. You do not need to wait for me to come back from holidays.”
In any case I’m ready to do my part. @perry you can count me in as a maintainer for ocaml-community. I encourage anyone motivated to do the same.
I agree that it’s important to have people who feel responsible for particular packages in the community repositories. I don’t think anyone here wants it to be a landfill. That said, it will be nice to allow a broader group of people to take responsibility in many instances rather than leaving the burden on single individuals.
Feel free to propose changes to the document. What’s there now is a strawman, and improvements are very actively solicited.
I also see ocaml-community not as a landfill, but as a way to give more people write access to repos that I will otherwise continue to maintain.
Also, if we have consistent easy issue labeling in ocaml-community, we can have a bot listing all the easy issues in one place somewhere. Beginners may be happy to help out with them. We had good experience with this in Lwt.
Can we use the same bot?
I don’t think we even need a bot for this. A redirection to a simple github search for something like
org:ocaml-community label:beginner
would do.
@bluddy Nice, I didn’t know GitHub could do that.
@perry I meant we had a good experience with people taking on easy issues in Lwt, not that we have a bot 
We also just redirect to a GitHub search, but I didn’t realize it would work across repos how @bluddy suggested.
I think it would be fitting for each package in ocaml-community to have a few explicitly-listed maintainers, to take responsibility (in particular, review other people’s PR if no one steps to do it), in addition to the implicit agreement that other members can take care of things. The explicit maintainers can be just those listed in the opam file.
@gasche One option for that is to use a CODEOWNERS file for each repository. That will automatically trigger adding the specified people as reviewers.