dev meeting 20210217

Present at the meeting:

• Guillaume Petiot (@gpetiot)
• Nathan Rebours (@NathanReb)

Current plan

• Nathan finishes the last reviews required for the 1.5.0 release
• We prepare the schedule for the 2.0.0 release at the next meeting

Meeting notes

Guillaume brought the branch sanitizing PR back to life as decided during last meeting and it's now been merged! He also spent some time with Nathan to fix the draft mode PR which will finally make it into the next release. The bug was that we were looking for the wrong release asset in the github response when undrafting as github applies some sanitization to the asset name. We now record the uploaded asset name during publish and use that name when undrafting.

While reviewing the Git Sanitization PR from Guillaume Nathan found out that github changed the way it named releases by default and made dune-release explicitly set the release name when publishing to keep consistent release names. He spent some time reviewing Sonja's PR to add the check command. There are a few things to adjust there but two interesting things came out:

1. The behaviour of the --dry-run flag in the command is a bit suspicious and made us realize that we might need to further specify what dry-run means. We also need to wonder when does it actually make sense to allow using this flag as it might not be necessary for command that do not modify versioned files nor try to write anything. At least what seemed to be clear is that check might be one of the commands where the flag isn't necessary as we're not actually trying to publish anything.
2. In the current PR state, the command checks that the user have internet access by pinging github.com. While this check in particular isn't especially meaningful and should probably be removed from the PR, it might be useful to have a way to check that your configuration for "online" interaction is valid, in particular it could verify that your registered opam fork exists, that your github token is valid or that you have the correct access level to the repository you're trying to release. In a first iteration I think check can stick to local verification but that's the kind of interesting follow up we could work on.

While discussing all this we brought up the topic of the initial configuration step for dune-release. Users recently opened issue because they were unable to properly fill the fields when first prompted to. We should probably polish this part of the tool as new comers most likely don't know how opam package releases work and therefore might have no idea what information to input there or why they have to provide it to dune-release in the first place. We'll look into walking new users through that step more smoothly. We probably need to write more online documentation for dune-release (Guillaume suggested using the github Wiki to have a more structured documentation than a flat, thousands of lines long README) but this is the kind of place where the tool should guide users so that they don't have to read the whole documentation and understand how it works to answer correctly. It probably make sense to duplicate information between online doc and dune-release logs and man pages.

We're closing in on 1.5.0 and as previously stated, once it is released we'll mostly be heading towards 2.0. dune-release.1.5.0 should be released by next meeting so we'll probably slightly extend it so we can devise a clear plan, including what are the key features we want to include in 2.0, a time estimate for the decided set of features and changes and according to the outcome of this, a clear plan on how we're going to handle it (most likely breaking master and extracting a 1.x branch to cut point releases if need be).

Until then, no further work on dune-release except getting the last two PRs merged!