dev meeting 20220112

Present at the meeting:

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

Current plan

• Sonja creates an issue for improving guidance when token needs updating
• Marek creates an issue to migrate configuration files to sexp instead of custom yaml
• Nathan creates an issue to migrate Github API calls from REST to GraphQL
• Nathan labels 2.0.0 issues with breaking change when necessary
• Marek works on dropping support for opam 1 (client and file format)
• Nathan works on removing delegates
• Sonja works on the renaming/removal of the bistro command
• Sonja works on integrating tag into the main/default command
• Nathan look into fixing the draft workflow

Meeting notes

Not much has happened on dune-release development on the end of 2021.

Marek helped an external contributor merging an improvement to the changelog parsing to support the keepachangelog format. As a result of the discussions there he also added a very welcome CONTRIBUTING.md to the repo!

Marek and Nathan have used dune-release to publish dune-ports to opam-overlays and identified a few quirks here and there. Among those were inconsistencies in the CLI flags and options between the individual commands and the main, default command. Nathan submitted a PR to fix those to help releasing dune ports.

We discussed issues Sonja found trying out the draft mode. Apparently draft release were private which triggered build failures on opam-repository CI since it couldn't get the archive from it. Nathan seemed confident this used to work and thinks it might be a change in github's default behaviour for draft releases or a repository setting that needs to be tweaked. Hopefully this can be set in the API request but either way we need to look into this.

Sonja reported that the odoc maintainers would like to push the ocaml v3 website centralized doc instead of individual gh-pages hosted doc websites. This sounds perfectly reasonable, especially since we consider that publishing the doc as is done by dune-release isn't the best option and we'd much rather rely on the centralized doc for released version and on a CI job to maintain an up to date dev version of the doc eventually. Ultimately we'll be able to remove the doc publication from dune-release but in the meantime we'll try to make sure that dune-release 2.0.0 doesn't deploy gh-pages doc by default, e.g. by making it only do so if the opam doc field points to github.io.

We also discussed the issue Kate had recently. A typo in a dev-repo URL lead to a weird authentication error on github to prevent malicious private repository detection. It should be possible for us to detect those cases when running the git commands and report the actual error which is "This URL is either invalid or points to a private repo. dune-release doesn't support private releases." Marek and Sonja pointed out that this could also be improved by using the github API for those operations instead of git. Nathan was a bit reluctant at first as those actually are git operations and that changing this could get in the way of supporting other hosting platforms such as gitlab or partial use of dune-release for non github hosted projects, which we'd like to support. Given gitlab support isn't on the roadmap atm it should not get in the way of such fixes too much but the other case is really something we care about. We agreed though that some operations only work for github atm (such as publish, which was what caused Kate troubles) and those can be moved to use the github API instead without risking harming alternative workflows. We'll need to do an inventory of which operations can be migrated. Good thing is that this should not break anything and can be dealt with after 2.0.0 if needed.