A few topics which we might want to address before we do a 2021.02.1 release:
Feedback on these topics and on additional topics welcome!
There is no Mac installer (ToDo)
This is the only topic I may contribute to (by finishing the DMG pull request). But you were working on it, so I did not. If things changed, just tell me.
One might want to add MacPorts and Homebrew packages for Coq Platform
I think this is outside the job of platform maintainers. What we have to provide is a good documentation so that other people can package the Coq platform for their preferred package manager.
The opam package for the platform could be a nice addition, but if you anticipate that it will often create issues, then better not provide it than to provide it and not update it. In other words, only provide it if this is something we can commit to. The scripts work just fine.
Regarding the mac installer, this is a high priority issue IMHO. I don't see how I can complete and merge https://github.com/coq/www/pull/162 without it.
When I renamed the branch I forgot to adjust the branch name patterns in the CU files, so CI did not run. I fixed this and CI does run now, so the installers should be available soon. I will give them a quick test as soon as they are ready.
Btw.: should we start to create forks and use fork branches for PRs so that the branch structure looks cleaner?
This is a good idea. I think GH lets you block the creation of branches or something like that, @Théo Zimmermann knows better.
Unfortunately, no, not yet. But this feature is now (finally :tada:) on the GitHub roadmap: https://github.com/github/roadmap/issues/166
If they respect their timeline, it should land in one month at most.
That seems like a much larger solution than needed. Would the current "branch protection" mechanism not be sufficient to prevent branch creation? For instance, I would expect that protecting the *
branch would prevent any new branch from being created, would it not?
No, I've tested this but it doesn't work like this. Anyone can create a new branch but then that branch is protected (and thus no one can delete it). With the new mechanism (which I agree is much bigger than what we need), we will be able to restrict who can create new branches and how they can be named.
Théo Zimmermann said:
then that branch is protected (and thus no one can delete it)
Seems like someone did not think it through... Depressing.
GH: "all your branches are mine"
Just a note: since some CI is still running, I decided to do the branch renaming tomorrow first thing:
master
will be renamed to dev-ci
2021.02
will become the default branchI try to extend the CI over the weekend so that nightly builds run on both dev-ci and 2021.02.
P.S.: Should I do the release tag before or after that?
I don't think it matters much. As long as everything is up to date in the 2021.02 branch when you tag.
@Enrico Tassi : when do you expect the signed installers? I would do the release when you have them, so that we can add them immediately.
@Théo Zimmermann : you said before that the release notes should be more ealborate, e.g. contain the package structure, but isn't it sufficient to link to the Readme for that?
I sent them yesterday, they downloaded them (the privacy breach of filesender) but I did not get them back
I may ping them if I hear nothing by noon
it is weird, because they sign them evem fron home sometimes, e.g. 8.13.1 was sent back at 11PM
Wow, gihub show me a popup that the branch v8.13 was renamed with instruction on how to fix my local clone
FTR I started a job from the web UI to build and upload the snap package. Apparently they lifted the limitation: you can select on which branch you run it (so my curl hack is not needed anymore, strictly speaking).
I still need to improve a little the messages that show up in the little form, I'll open a PR
Screenshot-from-2021-02-26-09-53-05.png
I'm now happy with it, anyone with write access to the repo can run it and upload to the store. One still needs some credentials to publish the uploaded file.
I should share these with you @Michael Soegtrop and @Théo Zimmermann , how do you want me to send them?
By encrypted e-mail. Do you already have my GPG key?
@Michael Soegtrop Sure, as long as you say something like: see the README for the list of included packages and their version, rather than just "further details". Also, since we explicitly document the existence of both binary packages and scripts on the website, I think it is important that these release notes mention where to find the instructions for these scripts. The easiest way is probably to repeat the pointers to the three system-specific READMEs.
I.e. I would repeat for each release of the platform that it can be installed as a binary or from sources and where to find the relevant files.
@Théo Zimmermann : would you mind drafting the release message? Or shall I draft one and you review it?
@Théo Zimmermann @Enrico Tassi : are we ready for the tag?
I'm OK
(I still don't have the signed packages... but we can tag)
OK I'll draft something.
I've put a draft at https://github.com/coq/platform/releases
The links should work once the draft is associated to a tag.
Feel free to edit it further.
Thanks - very nice! When mentioning the Snap installer, should we refer to Readme_Linux?
Btw.: did we already discuss a naming scheme for the tag? Should it be just 2021.02.0 so that branch and tag names differ by length and not by a prefix?
I'd say 2021.02.0
is OK. I did ping the "windows signature masters", no news so far.
OK, then I do the tag as 2021.02.0. We can keep the release in draft state until the signed packages are there.
Btw.: did you have a look at the strange CoqIDE effect (that it hangs on the UniCoq smoke test file?)
Michael Soegtrop said:
Thanks - very nice! When mentioning the Snap installer, should we refer to Readme_Linux?
Indeed, why not?
I did the tag and a few minor changes to the draft release (one larger change: the release was called 2021.02.1, I changed it to 2021.02.0).
@Théo Zimmermann : are you sure that links without path/version go to the respective release and not to the default repo?
Yes, I'm sure.
I got a "we will do it now" from the signing masters, I'll forward you the email with the links. Then I have to go and I'll be back around 5PM. BTW, I realize now that I don't need to share any credentials with you, I can just add you to the list of collaborators on the snap package
Great, that's even better!
if you already have an account on https://snapcraft.io/ then tell me with which email
Not yet. I'll send you the info when I create one.
it is not clear if you have to
they ask for any email
tell me which one you would use and I'll try
I would use my Gmail email for this kind of thing.
I don't have it
I found it and sen you the invite
Yes, I've received it!
FTR, I still have the credentials for the owner of the snap, which I may want to share anyway (the recovery email is coq-team but still).
e.g. I don't think you will be able to add collaborators
@Enrico Tassi : I received the installers and will upload them now.
I did the release on GitHub :-)
@Enrico Tassi in addition to the announcement email, I'm thinking this should get a news item on the website.
I'm back but I have a call. @Théo Zimmermann you did not accept the snap store invitation apparently
BTW if you two have 5 minutes around 5PM I can give you a mini demo of the snap store, to put you up to speed.
Yes, I've got 5 minutes at 5pm. But not much more than this because I need to be somewhere else before curfew.
I've accepted the invitation now.
sorry I"m late
@Enrico Tassi If it's actually just 5 minutes, it's still OK for me.
But we can also do this another time when @Michael Soegtrop is available.
Let's do this another time.
lets do another time
sorry, the meeting did overflow
Hi, I am available now. Anything left to be done?
I'd say no, maybe review/merge https://github.com/coq/www/pull/165
And yes, for the snap store I need an email of you to send you an invitation, this way you will be able to manage the package without sharing credentials
Which email do you want me to use?
did this break ci? https://gitlab.com/coq/coq/-/jobs/1059254561
@Gaëtan Gilbert : sorry - yes. We renamed the master branch to "dev-ci". This needs to be adjusted in the scripts. I will to a PR right away.
https://github.com/coq/coq/pull/13884
Thank you all for your help with this - time to celebrate!
@Michael Soegtrop for the snap store I can send you an invitation, this way you will be able to manage the package without sharing credentials.
Which email do you want me to use?
(you can also no, it's just that I want to be sure you did not miss my previous message)
Last updated: Jun 03 2023 at 05:01 UTC