dev meeting 20211020

Present at the meeting:

• Sonja Heinze (@pitag-ha)
• Marek Kubica (@Leonidas-from-XIV)
• Nathan Rebours (@NathanReb)

Current plan

• We create clear and detailed issues for each element of the 2.0.0 roadmap

Meeting notes

We collectively assembled a roadmap for 2.0.0 since last meeting and reviewed it today. It feels like it is reasonable enough get everything ready by Q1 for the release. The bigger items include the high priority refactoring of the integration tests. This has to be done first, it will be hard to work on a major release if we can't rely on our test suite. Moving from MDX to cram, documenting the test cases better and reduce the amount of noise in them are the key aspects of this refactoring. The removal of delegates and the follow up simplification of remote repo detection is also a bit of work. Moving the entirety of our github interactions from the REST v3 to the graphql API will also likely take a bit of time but besides those three heavy tasks, the rest should be either very simple and small changes are independent pieces of work that can be worked on in parallel.

We discussed in more details some of the items.

In particular we talked about the "no-config" dune-release workflow. As part of 2.0 we'll make the configuration optional (except for the Github token), using the API in depth to lookup — and eventually create — the remote fork of the opam repository, creating a branch, commit and open the PR all through the github API without requiring any local setup or input from the user. Marek mentioned it might be good to completely remove the configuration. Nathan believes it might be good to still allow users to configure it to use local clones as it used to. This has been working fairly well for some users and removing this from them might feel a bit unasked for. Nathan quite appreciate that it sets up its local clone so that if further work is needed on the release, everything is ready, you just have to cd into it. The new workflow will be great for new users or advanced users that would prefer dune-release not to temper with their local setup. It will be interesting to see what people use and prefer once this is released. We can then delete the config entirely if nobody wants to use it in the end.

We briefly talked about the move from REST to graphql. As we realized in the past, the REST API is not really well maintained anymore and we already have to go through the graphql API for some specific interactions that are bugged under REST.

We talked about the dune-project parsing thing and parsing of config files in general. For a brief moment we thought we could get rid of the dune-project parsing as we don't want to use the project name to determine the name of the tarball in multi-opam repo and use the git repo name instead, extracted from the dev-repo field of the opam files. Problem is we have to parse dune-project files in the check command as we need to make sure the project name is set to prevent dune subst from crashing later on. We'd like to use a proper sexp parser for dune-project files. We believe it would aslo make sense to use sexps for our configuration files so that we use the same format than dune does and we can share the parsers. This will need us to migrate the configuration from the old format until the next major release but it's probably worth it in the long run. We'll need to see which parser to use as sexplib is a bit of an heavy dependency atm. Ideally we'd like to use opam monorepo or some custom opam executable installation so that our dependencies don't polute the user's switch but if not, we'll have to settle for a minimal parser such as the one @gpetiot is maintaining.

We also identified priorities among the roadmap items. We'll make sure to include them in the final set of issues for the 2.0.0 milestone. Over the next week we'll work on creating issues with the proper context and detail level so that it's easy for new contributors to join in on the effort and for us to organize work on 2.0.0.