dev meeting 20200902

Present at the meeting:

• Guillaune Petiot (@gpetiot)
• Sonja Heinze (@pitag-ha)
• Nathan Rebours (@NathanReb)

Current plan

• Sonja looks into the linting phase, list the various checks and classify them either as mandatory (always run when building the tarball) or lint (run as a separate step that can be disabled).
• Guillaume finishes the draft workflow
• Nathan allows including the dune subst in the tagged commit
• Nathan tries to replace MDX by dune's cram tests

Meeting notes

Sonja worked on deprecating the delegates and improving the deprecation warnings by adding a dedicated module. The PR is opened and awaiting review.

Guillaume did quite a bit of work to fix bugs from the issue tracker. There are a bunch of opened PRs, Nathan he's taking a look at them.

Nathan haven't had much time to work on dune-release lately but is planning to review pending PRs and work on the dune subst inclusion in the tagged commit.

We discussed some issues/complaints we received about the tool recently, especially how hard it sometimes is to use dune-release to only do parts of the release. The outcome is that one should be able to use parts of dune-release if they wish to release elsewhere than github, that's part of the contract with the delegates and their soon to come replacement. Releasing to github though should be left to dune-release and there is no particular plan to support doing part of the work by hand and part of it through the tool, at least not unless you agree to follow certain rules. There are already CLI options allowing one to override certain defaults from dune-release and we will continue to support such fine grained configuration but we don't plan on making the tool aware of every possible variations in a github release by default. One thing we must support though is recovering from failures, without having to delete everything and start all over again. In particular we agreed that dune-release should skip pushing the tag if it's already present and pointing to the right commit on the remote repo. Same applies for an existing Github release. Users should be aware that this is only intended to work for tags and releases compliant with dune-release (i.e. as if previously generated by the tool itself). If this allows some users to do these part of the work themselves, it is only a nice side-effect but in no case a feature we intend to maintain at the moment.

One other important thing we noted is that opam-publish users are often confused at dune-release when they first try it. We should write a short guide about how to migrate from one to the other to make sure they don't get the wrong ideas and have a pleasant introduction to the tool.