Hi all, this is a thread to discuss everything related to the 8.12 release. For now, recall that the branching target is May 15th, so these are the last days to get Pull Requests that are not bugfixes merged in master
Hi all, branching is expected to happen very soon. At this point only fixes and documentation improvements are allowed to target the 8.12 milestones; there are some pre-existing PRs that could still make it if they get processed in the next couple of days. If you have any question or request please don't hesitate to get in touch with us,
Théo and Emilio
I've created this https://github.com/coq/coq/issues/12334 and read the first paragraph. I won't have time to do any of it before Monday. BTW, it seems that creating the alpha tag is better done by the one that makes the 8.12 branche no?
Indeed @Enrico Tassi , good point; we will push the tag. The problem with the tag is that it is supposed to be placed on the _first_ commit not in 8.12
so indeed we cannot do when we branch, as we need to wait for a PR to be merged in master first
Great, thanks @Enrico Tassi. My view is that the best course of action would be for the first PR to be merged into master after the branch be the one that updates the version number. And then, the tag would go on the commit this PR contains.
So, we should probably reorder the two corresponding checkboxes.
Maybe it would make sense to "shift" the creation of this PR (the one doing the version renaming) https://github.com/coq/coq/pull/11158/files from RM n+1 to RM n, and have this tagged.
Anyway, I can tag on Monday myself, I'm just trying to understand how the process works
In fact, the most important thing to my eyes is that this is the 8.12 RM which merges the PR bumping to 8.13.
(I won't be able to prepare it before monday afternoon)
Since we are two 8.12 RMs, if you agree with this plan, I can take care of preparing the PR, and @Emilio Jesús Gallego Arias can take care of merging it.
Sounds good
As you like
less work for me ;-)
Actually the create-branch
script could do all this; branch, push the branch, create the commit, submit the PR, merge it, and push the tag
Yes.
I wanted to work on such a script but did not do it yet, maybe I'll do it now.
It would be nice, but your PR 11158 is not exactly trivial
In particular it is not a simple sed, there is ADT with V8XX and some code matching on it.
A lot of it is already generated by a script
(dev/tools/update-compat.py
)
You are right, I did not read the paragraph at the end
BTW @Enrico Tassi did you copy the content of this new issue from dev/doc/release-process.md
or from the 8.12 issue?
It looks like it isn't in sync with the latest changes...
hum, no, I did the silly thing. It says copy "this" and I interpreted it strictly
let me update it
Which one is not in sync? I guess the one in dev/doc
?
The one in dev/doc
is the correct reference.
Because it is the one that we update when we want to make the process evolve.
But now, I'm thinking that we could have the bot do many of these things for us, including opening the next "release issue" whenever we check boxes.
done, it was silly on my side, anyway I clarified it. now it should be brainless-compatible
This does look more up-to-date to me :slight_smile:
@Théo Zimmermann I think I may have done a pass on the issue that was not reflected on the .md
file
Interesting, then we might want to resync the .md
file to take into account some of your changes.
I've noted down automation ideas in coq/bot#51. We'll see if I finally get an intern this month and if this is something that he can push forward.
@Théo Zimmermann something we don't have is a way to block PRs with the 8.13 milestone from being merged.
We are keeping a (manual) eye on that, but yeah, it is far from optimal.
Let's create a needs: next release branch
Since the needs:
labels are checked by the merging script.
However, if a PR accidentally ends up being merged before the branching with the 8.13 milestone but it is actually fine for 8.12, then we can just fix the milestone (I did that for three PRs which had been milestoned as 8.12.0 but were merged so should have been 8.12+beta1).
Yeah this is something the bot could do
Indeed, such things could be checked as part of a major revamp of the automation for release and backporting management. Let's see what my intern can do about this, this summer (if the internship finally happens).
Is there an update on when the 8.12 branch is done? (Or conversely, are there PRs on which prioritary reviews have still to be made? Which for me would be after 6pm GMT+2 though.)
Hugo, we are about to branch
OK
I don't see anything urgent, thanks; stuff seems under control.
A couple of PRs seem that won't be ready, but IMO not a big deal
We can always backport if we think delaying is a mistake
@Théo Zimmermann , you see something urgent in the sense of what Hugo asks?
Nope, all is good!
Finally some time. I see the branch was made, as well as the commit coq/coq#ea6cb6b542e8c356192bb77f234586e0f6d55c8c. Should I tag it with V8.13+alpha?
Oh, I see emilio told me in a PR, ok
Note that the first 8.13 commit is not the merge PR but the merge parent
(so that would be f123874
, cf. our comments on this commit)
Well, never mind. We haven't been very consistent in this practice anyway.
uff... I'll fit that, but I don't what would be the difference
fixed
Théo Zimmermann said:
Well, never mind. We haven't been very consistent in this practice anyway.
What do you mean?
In the past, there were many alpha commits that targeted merge commits.
The VX.X+alpha tag marks the first commit to be in master and not in the
branch of the previous version.
Apart from that, I don't see how I should have understood that from the text above
Yep, the spec is a bit imprecise.
To me the first commit landing in master is the merge one
It used to be my interpretation as well.
But like I said, that's not a big deal.
Théo Zimmermann said:
In the past, there were many alpha commits that targeted merge commits.
8.11 / 8.12 were correctly set; IMHO this not something we can ignore, tagging on the merge commit is incorrect
Can you explain why?
use git log --topo-order
the first commit to land in a branch can never be a merge commit
in the sense that by topological ordering the parent commit would not be on the branch
so if you tag the merge commit
the commit that is actually merged
won't be considered to be part of 8.13
but won't be part of 8.12 either
so would we had tagged the merged commit, f1238742f931269167e7c2704b53bb285d05f39d would be orphaned in terms of tags
git describe
for example would have found the 8.12 parent
incorrectly, this was discussed in 8.10/8.11 I believe
ok, that is a good reason. I'll clarify the doc
Thanks
But yeah, first commit not in a branch is determined in git-land by topological order, descending from the earliest merge point ; to avoid confusion there are scripts around that do that
Coq 8.12 projects for backports seems to be working correctly! @Théo Zimmermann
We can test the first backport soon
Yes, but let's pin ci-basic-overlay.sh
first.
Salut @Théo Zimmermann , where we are at the beta? It seems to me we could try do the packages even today
right?
Barring a few things, it seems that we don't expect a lot of changes
WDYT?
Two main blockers:
What do you mean doing the packages? Tagging? I don't think this is doable today and to my eyes there are several blockers:
Thanks for the detailed summary @Théo Zimmermann ; I've adjusted a few issues. I was referring to building the test packages; IMO we may want to try before the beta tag to see if there are any build problems [as you mentioned] and to have some testing. Once we have tested we can proceed to tag.
Then, yes, it should be possible to do this pretty soon (main issue is fixing the coq-menhirlib issue).
OSX packages should be actually testable right now, right?
For Win we can disable compcert for now; and try to see what happens
I'm pretty unhappy with the approach used in the Windows build
OSX packages should be actually testable right now, right?
Yes, and they are continuously generated so we could already request someone with a Mac to test them.
For Win we can disable compcert for now; and try to see what happens
Yeah, that would work.
I'm pretty unhappy with the approach used in the Windows build
Me too, but the reason why I've not been in a hurry to fix this is because of the upcoming platform.
(which should make this obsolete)
@Théo Zimmermann , it seems that once we process https://github.com/coq/coq/pull/12429 , and the doc PRs [these are ready tho] we could try to tag, WDYT?
As I wrote on the Github Actions thread, it is feasible to bulid 8.12 Win packages using Github Actions, if we would like to do so.
Of course we would not be able to remove the Inria-cloud packages yet, but if you think it is a good idea we could provide both sets of windows packages in the beta
After looking at the PR, I am not confident that you will manage to have the infrastructure in place soon enough to generate the 8.12 beta Windows package with GitHub Actions. But if you do get there in time, then I would be happy to replace the GitLab CI setup with Inria runners. Why do you say we would have to ship packages generated with both?
I can have a working version for this week; the problems are due to the complex interface to the current build scripts but I will fire my win VM up and should solve all the problems. Cygwin install went in the way it had to do so that IMO was the most critical issue.
My point about still having both packages is that we are quite late, I mean we should still have to generate both packages for a while, and only when the Azure package has been more tested we could think of actually replacing it.
WDYT?
If this is how you see things, then I think this is an argument to say this infrastructure change would be 8.13 material.
I'm really exploring options @Théo Zimmermann , I don't have a particular view; I'm perfectly fine with the win build rework being 8.13, but of course I'd like to hear what you think
The only positive point would be if migrating does make our life easier
but indeed if we deem it too risky that's a no go for 8.12
I think it might, but just a little. And I think the risk is reasonable if we do the change in the beta.
I'd say let's finish the GH actions packaging anyways, and we re-evaluate
But I wouldn't keep both even for a limited period.
:+1:
My personal view is that we should take as little risk as possible, so I propose this:
I'll finish the PR tomorrow
then we see how the diff looks
and make a choice
even so we should keep the backup for a while, just in case, but I'm happy to take care of that
my win VM is almost ready
OK
Regarding the IDE issues, I'm unsure what to do with them.
One of them is certainly not a regression so could easily be postponed.
The one reported by Enrico might be a regression. We should check if we can reproduce it. If it only happens through Wine, it is not a big deal.
While trying to build the Windows package with add-ons, I got a failure in Unicoq:
Dynlink error: The module `Int_misc' is already loaded (either by the main program or a previously-dynlinked library)
Do you know how to interpret this? Could it be related to coq/coq#12421? (I only tested after backporting this PR.)
This is due to many Coq plugins broken in OCaml >= 4.08 , there is an open issue already
Oh OK, so the easiest solution is to downgrad OCaml to 4.07, right?
See https://github.com/coq/coq/issues/12067
I think for now yes
@Théo Zimmermann : I wanted to ask what remains to be done for the version picking. Please note that I am still working on improved makefiles for VST which use a platform supplied CompCert. There is an open PR from me at VST which needs a bit more work. It might not be ready for the 8.12 beta but I hope to finish it within a week. Anything else?
@Michael Soegtrop thanks for asking! I definitely need your help. See coq/coq#12415.
You mean you need a Windows build server maintenance run? Luckily I am at home - I will look into it.
This (thanks!) and help on fixing menhir, making sure CompCert and VST work, as well as Gappa and Interval.
@Théo Zimmermann : what the time line for the release? I didn't start to look much into it, because until yesterday I really had 0 time and I thought it would more disturb than help if I get involved except with answering specific questions since timeline was early this week. But now it looks better on my side and also the time line looks more relaxed (which always happend in the past when doing the picking). If you say it is now more next week Monday ...
I think we will release as soon as we are able to, which could be indeed around early next week.
We are still waiting for a release summary (Matthieu is working on this) and a few infrastructure fixes in the refman.
But if it turns out to take too long to find how to properly build some add-ons we may remove them from the beta installer to avoid further delaying the release.
But if it turns out to take too long to find how to properly build some add-ons we may remove them from the beta installer to avoid further delaying the release.
Fair enough. I think for the beta it would be ok to take VST from my fork. The platform friendly build is fully working, even with 32 and 64 bit dual install. What is not working is support for some legacy build situations some people need, but I think it woul dbe fine to not have this in beta. I will discuss it with Andrew.
So I take VST, CoqInterval and Gappa?
Yes, thanks!
OK. You also mentioned menhir above? What's the issue with it?
OCaml 4.08 for the menhir executable or Coq 8.12 for the Coq library?
It is dune based now?
Yes.
See the corresponding commit (a99b4da
) in coq/coq#12415.
See also the build failure in https://github.com/coq/coq/pull/12415#issuecomment-638711264.
OK, that should be doable. So I can also look into menhir, but I will start with the other 3. When I am finished with these, I will let you know and we can discuss who does menhir.
I thought menhir was a dependency of CompCert and thus VST, and this is why I started by looking into it.
I thought menhir was a dependency of CompCert and thus VST, and this is why I started by looking into it.
Indeed, so I guess it is better if I start with menhir. Or I start with Gappa and Interval and you look into menhir meanhwile - as you prefer.
I've spent too much time on this already and I'd like to attend to other issues so I'd be happy to give you the full hand on this PR.
OK, fine. The dune discussion group is only a click away :-)
So I will do Menhir, VST, Gappa and CoqInterval, likely in that order unless I get stuck somewhere.
@Matthieu Sozeau We are getting closer and closer to being able to tag the beta. When do you think you will have the release summary ready?
I'm working on it this afternoon, I'll submit a PR by the evening
How do we count the merged PRs and closed issues since 8.11? I don't think we have a process for that, do we?
Doing a github search with "is:pr is:closed milestone:8.12+beta1 label:"kind: fix" " seems good enough
Why only the fixes?
To know how many we fixed in the period
Ah! But you could have filtered the closed issues in the milestone! coqbot adds issues automatically to the milestone of the PR that closed it.
@Théo Zimmermann you want to target all fixes to 8.12.0 already, or these is time for the beta?
For example https://github.com/coq/coq/pull/12471
We don't know yet for sure when we will tag the beta as it depends on the completion of a few remaining PRs, so until we do, I'd say fixes should still target 8.12+beta1. We can easily postpone them when the time comes.
Indeed, I'm readjusting at least one issue
So things look pretty good right @Théo Zimmermann ? I guess https://github.com/coq/coq/pull/12103 is the last thing blocking the beta ?
[We can take care of the Release notes emsemble I think]
coq/coq#12103 is not a blocker: if it is ready before the beta, good, if it is not, no problem: the URL we should advertise for the manual will be https://coq.github.io/doc/v8.12/refman, which is a moving target, therefore it is not a problem if a doc PR is not included in the beta (except the release summary of course).
We should just give @Michael Soegtrop the day to finish his work on the add-ons. By the end of the day, if Gappa is not ready, I propose that we remove it from the beta (the rest of the add-ons should be OK).
Sounds good, we can backport the last couple of fixes that went it today then, let's finish the release notes and maybe we can branch on Wed?
we can tag I mean
would you like to release on time for the Coq workshop? IMO is doable.
Yeah, I was even hoping we could tag tomorrow, but maybe that's not actually realistic.
Tomorrow sounds fine
Emilio Jesús Gallego Arias said:
would you like to release on time for the Coq workshop? IMO is doable.
If the beta goes well (no unexpected serious problem), then yes.
So, we are very very close to being able to tag. There are still two PRs targeting master
and which are ready to merge @Emilio Jesús Gallego Arias (coq/coq#12481 and coq/coq#12492). In particular, I need the latter one to finish the add-on pinning.
Besides this, the main remaining thing to discuss is what to do with the deprecation warnings for terms as hints (coq/coq#11970): leave it; remove it; or replace it by the proposal at coq/coq#12493.
I think that PR seems to tricky for 8.12 IMHO
One that we should maybe consider is https://github.com/coq/coq/pull/12479
That seems to me like the kind of change that is important to have early
Nah, we give reviewers a chance to have it merged in time. They didn't react. This is now 8.13 material.
@Emilio Jesús Gallego Arias It looks like we are very very close to tag. I propose to postpone the last two issues and to close the milestone (it will signal not to add new PRs to the milestone but doesn't actually prevent us to add some, like the PR changing the version number).
Sounds good @Théo Zimmermann , indeed we are ready to tag
we need to add a note about OSX
minimum version
and little more
I guess we want to merge the last PR before closing?
Shall we announce the beta after the tag then?
Emilio Jesús Gallego Arias said:
we need to add a note about OSX
The two previous releases (8.11.1 and 8.11.2) had the same limitation though. If you want to note it somewhere, it could be only in the GitHub release.
Emilio Jesús Gallego Arias said:
I guess we want to merge the last PR before closing?
On the contrary, I was suggesting to close now, before it is empty, as a way of signaling that there should no longer be new PRs added to it.
Emilio Jesús Gallego Arias said:
Shall we announce the beta after the tag then?
Usually, we announce to Coqdev as soon as the tag is put that packages are ready to be prepared, and then take the next day to update the website, create the release on GitHub, upload the installers, and do the proper announcement.
Ok, let's close then
We had an error in the Windows 32 bits build on v8.12
. This was the first time that we tested it with all add-ons in fact (oops). That being said, it is "just" an out of memory error while building Coq-Elpi, so it is likely non systematic and I've thus restarted the job. But I won't put the tag before CI is fully green.
Coq-Elpi has one test about a huge inductive that is indeed memory hungry. You can probably disable it if it is a problem on 32 bits (I don't test it there)
OK, can you open a PR that disables it? Depending on whether it fails twice in a row or not, we can decide to merge it before or after tagging the beta.
theories/derive/tests/test_bcongr.v uses ~3G here, as the name says it is a test so removing it from _CoqProject is not a problem
(3G on 8.11 and 64bit 4.07)
Théo Zimmermann said:
OK, can you open a PR that disables it? Depending on whether it fails twice in a row or not, we can decide to merge it before or after tagging the beta.
I can open a PR, but on which project and about what? A PR on coq-elpi removing the test? A PR adding a patch to the windows build?
How much memory do the worker have? I hope more than 3G
Also 32 bit should use less memory...
A PR adjusting the Windows build. I should be able to do it myself with what you just explained.
@Enrico Tassi Can you help me fix coq/coq#12501?
I closed the GH tab, ping me here again if you need me
@Enrico Tassi For which ref did you prepare your patch? I cannot manage to apply it.
gares@ollypat:~/LPCIC/coq-elpi$ git describe
v1.4.1-1-gdcdf72a
I had an open windows, I did not think about it since these tests did not change in the last year or so
I'll push the commit on GH
on top of coq-master
OK but I'd rather need it on top of coq-v8.12...
there you are
Thanks
I still keep them disabled in coq-master, if ever we run the windows job...
Hopefully, this time everything should work out fine. But let's still wait for CI to fully pass on v8.12
before tagging.
I'm currently creating the GitHub release but it takes forever to upload the installers.
I have a fast connection if that can hepl
It's already ongoing, so I just need to wait now.
I'd just like to point out that 8.12+beta1 has been on core-dev
OPAM for a while, perhaps you guys can ping Érik when the official release happens about the Docker images? Haven't seen him for a while here.
is there any Nix 8.12
version now (aside from the v8.12
coq-on-cachix) we can use in CI? If not, is this planned to happen soon?
It has been merged into nixpkgs master. It should reach nixpkgs-unstable pretty soon.
@Théo Zimmermann : I managed to come up with a platform friendly make file for VST and also a x86 CompCert opam package. There is already one merged (https://github.com/coq/opam-coq-archive/pull/1318) but doing further tests with VST I found that the installation method I chose there is not practical, so I did (https://github.com/coq/opam-coq-archive/pull/1319) to change it. In the end I decided to install variants in non standard folders where they can be linked from with -Q or -R. This is a bit inconvenient but all other solutions are quite complicated, hacky and errror prone. The way it is done in 8.12.beta essentially only supports 32 bit. I think we can leave it like this and do a 32+64 bit and possibly also a multi platform variant for the platform (I plan to do this during the Coq workshop next week).
P.S.: the VST PR is (https://github.com/PrincetonUniversity/VST/pull/406)
P.P.S.: I did't have time to look into the CoqIDE issues and likely won't have time for this before Thursday.
We will likely wait some time after the Coq workshop to release 8.12.0 anyway because having the two RMs also be the workshop organizers is a bit too much! :laughing:
OK, this relaxes things a bit. Anyway I think I mixed up the Coq Workshop next week and the Coq User Workshop which I think was supposed to happen last week (https://github.com/coq/coq/wiki/Coq-Users-and-Developers-Workshop-2020). Did it actually take place last week? I will participate in the Coq Workshop Su/Mo and reserved the rest of the week to prepare the platform release, which then can happen shortly after the 8.12.0 release.
It didn't happen in the end. I think it is supposed to be postponed and held virtually in automn.
If everything goes well, we'll try to tag 8.12.0 next Friday (17th). No more PRs with overlays please.
Milestone 8.12.1 should be created soon .
Hi @Théo Zimmermann , so where we are at?
We may discuss a couple of points in the call today, right? And then really freeze the branch?
We really need to figure out how to fix https://github.com/coq/coq/issues/12657 (macOS job failing).
And we need to take a decision on https://github.com/coq/coq/pull/12537 vs https://github.com/coq/coq/pull/12663 regarding the Search
bug.
These are the two main blockers that I can see.
The OSX issue is unfortunate :S we need help from an OSX user
Regarding Search I'd rather keep the semantics in < 8.12 , and leave @Gaëtan Gilbert patch to the kernel in master for some testing; for me it is too risky
both PRs are complementary so that's not a problem
yeah given the status of the milestone I think we will have to tag next week maybe
Emilio Jesús Gallego Arias said:
The OSX issue is unfortunate :S we need help from an OSX user
I'm afraid an OSX user is not gonna suffice.
Théo Zimmermann said:
And we need to take a decision on https://github.com/coq/coq/pull/12537 vs https://github.com/coq/coq/pull/12663 regarding the
Search
bug.
About #12537, to be on the safest side, but also so that the new features of Search
are fully functional, I propose to make a (one-liner) fix one step closer to the original code (see my last comment there which explains the - avoidable - assumption made by the patch, AFAICS).
@Hugo Herbelin I'd prefer https://github.com/coq/coq/pull/12693 I guess; what do you think?
Emilio Jesús Gallego Arias said:
Hugo Herbelin I'd prefer https://github.com/coq/coq/pull/12693 I guess; what do you think?
https://github.com/coq/coq/pull/12693 looks nice indeed.
For the mac issue, I have a different suggestion, and I hope it's wrong: to get ruby 2.6, install ruby
instead of ruby@2.6
, and keep the same snapshost from 2019-09-03
.
2.6.x was the latest Ruby release in September 2019, so I'd bet that's what you'd get — see the dates of these URLs:
https://www.ruby-lang.org/en/news/2018/12/25/ruby-2-6-0-released/
https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/
OK thanks for the suggestion. It's worth trying that indeed.
But actually, our configuration never mentions ruby, it looks like it is just installed as a dependency of adwaita-icon-theme, so I'm not sure exactly what to change.
I'm wondering if it's not just that the trick to pin homebrew is unsound and the database of known packages isn't in sync with the pin.
Hm, it's not even a dependency of that package
_however_
you're pinning the formulas but not Brew itself
also the image has a bunch of extra "taps" with more formulas that you don't need (and which might interfere)
Any idea how to remove those?
there's brew untap, I can give you a command — but that's a side concern.
Conjecture: maybe you should pin Brew itself as well to an older version.
Any idea how to proceed to do that?
At the very least, Brew itself still uses ruby 2.6.
/usr/local/Homebrew is a separate Git repo
$ cd /usr/local/Homebrew; git remote -v
origin https://github.com/Homebrew/brew (fetch)
origin https://github.com/Homebrew/brew (push)
Just pinning this repo as well to a version from this date would suffice to pin brew? No need to recompile anything? (I guess not: Ruby is interpreted)
Ruby is interpreted indeed, but I'm not a Ruby expert, and this is still an unsupported config
Still, I might try:
for i in homebrew/cask homebrew/services mongodb/brew github/gh aws/tap adoptopenjdk/openjdk; do brew untap $i; done
I'm not sure how to stop brew from updating itself, but that might be a new enough feature
In retrospect, if that doesn't work, skipping brew and inlining the installation instructions from your old versions, maybe just for gtk, might be simpler.
IOW, bump Brew, use brew install gnu-time opam pkg-config adwaita-icon-theme
without gtksourceview3, and install those libraries by hand (for this release)
Any of these choices is still duct tape, but bumping gtk version in a rush is more dangerous.
Thanks for all the advice! I'll try what you suggested. Longer term, since it looks like reproducible builds still aren't supported by brew, I wonder if it might not be a good idea to get the required dependencies through Nix. Although, not being very knowledgeable in macOS packaging, there might be other issues lurking if we were to try that.
Hope that helps. AFAICS, Brew's "reproducible builds" weren't even meant to address this use case.
I've never learned to use Nix, so I'm not sure I can comment on that — except that Nix installs binaries in non-standard paths, some of those binaries embed those paths, and installing Nix on MacOs 10.15 (used to?) require some surgery.
But IANANE (I Am Not A Nix Expert).
So some/all of that might be unintentional FUD.
OTOH, if you "just" need to pin gtk. and maybe opam and adwaita-icon-theme (as I'd guessed), inlining installation of those libraries _might_ not be a bad idea.
Ok, so I think we are close to be set modulo the OSX problem. https://github.com/coq/coq/pull/12678 is still a bit concerning tho and we didn't manage to get a quorum to discuss about it.
There are some recent PRs fixing notation bugs but I'm not sure if these should be delayed to 8.12.1
I don't think coq/coq#12678 needs any discussion.
The story is simple: devs agreed to deprecate, users were not happy, we undeprecate but keep a warning.
Umm, what is the concrete problem these hints have
we state they are fragile
but we don't say why
I'm not sure I'm happy with the warning enabled by default
now users are going to see it
and will wonder
"can I ignore this"?
if the answer is yes, the warning should only happen under +wall
if the answer is not, we should provide some more details
so call it a doc issue if you want
OK, maybe this is still an issue, but this is a compromise between what @Pierre-Marie Pédrot wants and what users want. The current situation is that we have a deprecation warning and users are not happy about it, so I'd rather merge this PR rather than doing nothing.
Sure we need to merge the PR, but we should improve the docs on two counts:
@Théo Zimmermann I think we should be set for tomorrow; the OSX problem is IMHO best workarounded by ignoring the brew failure; it would be great to discuss a bit on the hints warning, but I think we can aim to tag after the call
I tried to backport all remaining patchees, but ran into a problem with the setup; so I undid everything; a tad more documentation on this wouldn't hurt
but the patches backport fine [conflicts are "dummy"]
I can try the backport again if you give me the green light [my problem was related to the dummy commit, but I think I know how to workaround that now]
I've noticed that you have moved manually some cards in the Coq 8.12 project, then backtracked. In principle, you never have to manage these cards manually. @coqbot takes care of moving them when you push the backports to v8.12.
The way I generally proceed today is git checkout backport-v8.12
(the branch on which I prepare the backports and which is associated to coq/coq#12391), git reset --hard upstream/v8.12
, dev/tools/backport-pr.sh --no-signature-check XXXX
any number of times and git push --force-with-lease
(to the backport-v8.12
branch on my fork) to trigger CI in the draft PR.
This dummy commit thing needs taking care of only when you push to v8.12
if you want to make sure that the draft PR doesn't get closed.
But I still don't see any backport of the Equations overlay, that would be necessary to be able to backport coq/coq#12523.
The dummy commit thing is a bit confusing, specially as it removing .gitlab-ci which is the main goal of the PR to be open. I guess this should be documented a bit better ? [Or I missed for example the coqbot part]
I will backport the equations PR once I get the CI running
I can re-try the backports if you give me the lock
The dummy commit is just to keep the PR open when it is empty. I just gave you the instructions above on how I proceed. The fact that I start with a git reset --hard upstream/v8.12
is precisely to get rid of this dummy commit.
Indeed, I was wondering where to add the instructions, maybe in RELEASE_PROCESS.md ?
I pushed the easy backports to the backport-v8.12
branch. Feel free to push more on top (there's no dummy commit anymore).
Emilio Jesús Gallego Arias said:
Indeed, I was wondering where to add the instructions, maybe in RELEASE_PROCESS.md ?
Here or in https://github.com/coq/coq/blob/master/CONTRIBUTING.md#release-management.
Actually the reason I moved the cards manually was to signal I was adding the backports to the PR
If I understand correctly now I'd have to scan manually the branch and the column to see what you added?
Anyways I'm taking the lock, will push the remaining ones and prepare the overlays
Yes, but what I did to signal the ones whose backport I already prepared was to move them to the bottom of the column.
So the 7 bottom ones are the ones I pushed to the branch already.
And none of the above.
That's a good heuristic, thanks!
I'm still puzzled about the OSX package :S
maybe we can chat 5 minutes after the call?
Very briefly possibly. I must be AFK for about an hour between 17.30 and 18.30.
Yeah let's keep it very brief
It looks like there is a new issue in the Windows build: https://gitlab.com/coq/coq/-/jobs/650943712
Is this a Cygwin mirror being down?
Yup looks like a transient failure
We are running late with the call :S
So what should we do
the issue is quite tricky I'm afraid
Makefile.ide is doing very weird stuff to generate the GTK installer
Maybe we can leave the call now and have a chat now on BBB?
Ok I'm in your bbb room
@Emilio Jesús Gallego Arias I shouldn't have backported coq/coq#12701 without updating VST (the consequence is a failing VST), and I'm waiting on Michael to do the VST update so I'm going to fix what I pushed earlier to backport-v8.12
(and consequently, the PR order in the Coq 8.12 project).
Umm, shouldn't we just bump the vst_ref to something more recent?
oh well, the windows package
Ok, we should be almost set now
IMHO we only want to merge the one PR for hints
and the PR for the changelog
Also we need to update the equations poitner
as for vst, if it is not ready let's just disable the build in 8.12.0
Will push to the branch once the CI completes
Hey @Théo Zimmermann , so I think we are almost good, we should merge https://github.com/coq/coq/pull/12678 , then I'll backport the remaining changes, update https://github.com/coq/coq/pull/12734 , and we can merge the release commit and tag
right?
VST seems like I will have to stay in the pinned version
Regarding VST, have you followed the e-mail exchange with Michael?
I am a bit lost there
Other than this, yes, I think that you covered everything remaining.
CI seems to pass
There is no issue with the current VST version, but it was a pinned commit specifically for the beta. VST is releasing a new version now and the idea was to include it in the Windows installer for 8.12.0.
Michael is taking care of this but this has been delayed by some other things.
So he's saying he should have something ready tonight.
In any case, we'll use a version from his fork.
I see thanks, so not a real showstopper I think. IMHO it is getting a bit late so 8.12 may have to include the beta version if we don't hear soon
Ok rest of backports pushed to the CI branch
I'm gonna adjust a few issues
sorry if I'm not keeping up with discussions/issues, etc., but what's the current release prognosis? 8.12.0 soon or another beta?
8.12.0 today
8.12.1 in Sep
@Théo Zimmermann so i was wondering if an additional column in the release project would help
to signal that a backport is pending CI
Possibly. I used to have one, before I wrote the automation to manage the project.
:+1:
Ok so I think in around 1-hour the branch will be ready
pending adjustments on the overlays for packages if needed
Seems in good shape; tho it is quite a noisy release in terms of warnings [hints, omega, etc...]
Ok, CI is almost ready, will push to 8.12 soon
@Théo Zimmermann I've noticed that there seems to be a hanging changelog
due to it using .md
?
That's typical :frown:
Indeed that needs fixing
let me prepare the PR
OK, note that it is missing from the 8.12+beta1 section, not the 8.12.0 section.
ok pr done
I am a bit confused about the new file types. Which of the files generated by coqc do I have to install?
@Michael Soegtrop If you are talking about vos
/ vok
I think you don't have to install any of them.
Thanks @Théo Zimmermann , PR backported
will rebase release commit as soon as CI is OK
ok everything is ready , for some reason github didn't update https://github.com/coq/coq/pull/12735 after my push to 8.12 but that PR contains only one extra commit
Yes, I noticed this behavior already. GitHub only update PR commits when you push directly to their branch, and not when you push to the base branch.
Théo Zimmermann said:
Michael Soegtrop If you are talking about
vos
/vok
I think you don't have to install any of them.
Yes, I was aksing about .vos/.vok. I wonder why coq itself installs a few of these.
Also: should I install .glob files? The documentation says that these are intended for coqdoc. Is it so that when I don't install them and someone creates documentation for a dependent project, this wouldn't reference the pre installed library sources properly? Are there also uses in editors?
And I can't say I understand what the .aux files are good for.
Here's the windows installer of what essentially is the release if anyone wants to test.
https://gitlab.com/coq/coq/-/jobs/654490347/artifacts/browse/artifacts/
@Théo Zimmermann I let you tag
OK
If nobody already did that, I'll create opam packages
https://github.com/ocaml/opam-repository/pull/16876
@Maxime Dénès Can you send a request to the person signing Windows packages at Inria to sign the Windows installers for 8.12.0 (available at https://gitlab.com/coq/coq/-/jobs/655496286/artifacts/file/artifacts/coq-8.12.0-installer-windows-x86_64.exe and https://gitlab.com/coq/coq/-/jobs/655496287/artifacts/file/artifacts/coq-8.12.0-installer-windows-i686.exe) or let me know who this person is and what's the process to contact them?
Sure, I'll send you an e-mail.
@Maxime Dénès and @Pierre-Marie Pédrot: I'm currently attempting to follow the instructions at https://github.com/coq/coq/wiki/SigningReleases. After having created the SSH tunel, I run vncviewer localhost
in another terminal and get a single field to enter the password, no field for the username. From the e-mail of Vincent, I thought I would also get a field for the username, where I would need to type ci
and where I could check the keyboard layout (I'm already on a US keyboard anyway). In the end, my authentication attempts get rejected.
So, it's a mess.
The password that Vincent sent us is not correct IIUC.
It's correct up to a keyboard translation error.
Ah OK, thanks for the clarification.
I'll try to reverse engineer the correct password then.
I can retry connecting myself to give you more input
Let me try first, and I'll let you know.
OK.
also the signing script is horribly outdated
with laborious help from @Maxime Dénès we managed to sign the package
But you didn't update the wiki page?
partially
but if anything this would need a fresh script
and I hadn't time then so...
OK, I failed in my attempt to reverse engineer the password. Can you try to login again?
The signing tuto says to run coq_dowload
to get the sources? Do we really need the sources in addition to the binary to sign the binary?
:victory: all installers have been signed
I've edited the signing documentation and the prepare.sh
script. It should be much more straightforward to sign the macOS package next time.
I believe .aux files store information about proof scripts so that the second time you evaluate a file in async mode, it can skip even the proofs that don't have Proof using, and can also know which proofs it's not worth spawning a worker thread for
Jason Gross said:
I believe .aux files store information about proof scripts so that the second time you evaluate a file in async mode, it can skip even the proofs that don't have Proof using, and can also know which proofs it's not worth spawning a worker thread for
thanks for the explanation. So this means it doesn't make sense to install them for libraries since they are just an optimization for recompiling files one anyway uses in compiled form. And even if one steps through a library file it will still work - it is just an optimization.
After discussion in the Coq Call today we may want to move forward the planned date for 8.12.1 a bit
@Théo Zimmermann what do you think about targeting a candidate for end of next week?
I will take care of the issues assigned to me, @Hugo Herbelin would also like to push a few fixes for notations needed by SF
Sure, we can try.
I've already backported most of the backlog. For https://github.com/coq/coq/pull/12881, I'm waiting on a confirmation.
Emilio Jesús Gallego Arias said:
I will take care of the issues assigned to me, Hugo Herbelin would also like to push a few fixes for notations needed by SF
I made #13026 for SF and I believe that this is all they need.
As far as the 8.2.1 PRs I made are concerned, #13026, #12999, #12960, #12946 are looking for an assignee (they are quite simple).
Noted, thanks Hugo, may give it a go today.
@Théo Zimmermann how are we doing with this?
I'm positive I want to ship a couple of patches for 8.12
one in particular is required to make Dune work with native, as it fixes a bug we discovered with testing
Backporting queue is almost empty but this is not the case of the 8.12.1 milestone. Personally, I wouldn't mind putting the tag as soon as coq/coq#12919 is merged and backported.
The other bug fixes could wait. There will be an 8.12.2 release.
That being said, if people want a couple more days to merge a few PRs, that's not a problem either.
We should also recheck the installers before we tag.
When would you ideally like to have the cut off?
#12895 is pretty serious tho, i can take care of it soon
Also a couple of Hugo's PR should strongly go in, but I think I can handle these now
I don't have any preference regarding the cutoff date, but let's avoid delaying it too much since it seemed quite urgent to produce a new release for some users.
I am gonna focus on the remaining TODO on my part for this, @Théo Zimmermann I'll move some issues to 8.12.2 so please have a look later on to see if something looks off to you.
Sure, though I don't see much that would be blocking.
As I said before, I'm still waiting on a review / merge of coq/coq#12919.
I've already taken care of backporting all the PRs in the queue so far.
However, we have a serious issue with Windows packaging (cf. coq/coq#13065). This one will be blocking the release until it is fixed / worked around.
Yeah that's pretty serious, maybe we could just pin the corresponding cygwin packages?
That should not be too hard
We could also release and do the windows package later
Pinning seems more complex than expected. See the discussion in the issue.
We could also release and do the windows package later
If it takes too long to fix, maybe.
@Emilio Jesús Gallego Arias Do you have any remaining blocking issue for 8.12.1? For my part, after the Windows packaging fix and backporting the quotation fix, I don't. We should just prepare the release notes PR and have some people recheck the packages before tagging.
Yes I have a couple of things I'll like to get in; I'll process them today.
Pity the path issue is more tricky than it looks, I'll try to improve it too
@Emilio Jesús Gallego Arias Any update?
@Théo Zimmermann I'm busy with my talk tomorrow, but after the seminar I shall be able to get everything done, sorry for the delay
Only critical fix is change in the patch we added for Dune + native
So Dune + native can work in 8.12.1
yeah there we issues due to the way libraries are located
What is this patch? I didn't see it in the 8.12.1 milestone.
It is a one liner on the specific native output dir flag; I'm too tired to test it today sorry; will submit and hopefully finish the rest tomorrow, sorry again.
No worries.
@Emilio Jesús Gallego Arias Shall we move forward on releasing 8.12.1 and just stop trying to add new bug fixes in it?
The distance to the closest bug fix is divided by two every week :)
Ok @Théo Zimmermann , sorry for the delay, I've submitted https://github.com/coq/coq/pull/13193 which would be great to have in 8.12.1 if possible, for the rest we can delay tho I'm gonna try to address the open bugs now that I finished that one which was the prioritary for me.
Great news!
Ok, all other two bugs now have PRs that fix them and in theory could be backported
Hey @Théo Zimmermann , so we may try to release this week then? The pending PRs themselves are pretty trivial I think.
Sure, it has waited long enough!
So let's go for it, we need assignees for the PRs tho
@Emilio Jesús Gallego Arias I'd like an opinion from you whether to backport or not coq/coq#13284.
Then, I suppose we also need to wait for coq/coq#13331 to be in since it fixes a proof of False
.
Other than this, I was ready to open the PR bumping the version number in v8.12
.
Thanks @Théo Zimmermann , regarding the bug, the API breakage is very unlikely to have any impact, so I'd go with the maintainers, for the critical bug we need to discuss a bit more as I think there is still some fishy going but indeed seems like a good idea to wait :S , fix should be merged very soon I think.
Last updated: Dec 01 2023 at 04:01 UTC