Upgrade Externals January 2023

[mwoehlke-kitware]

Towards #18510. Fixes #17910.

---

This change is 

[mwoehlke-kitware]

+@jwnimmer-tri for feature review, please.

[jwnimmer-tri]

both reviews +(status: single reviewer ok).

+(release notes: fix) +(status: commits are properly curated)

Reviewed 1 of 1 files at r1, 3 of 3 files at r2, 1 of 1 files at r3, 1 of 1 files at r4, 1 of 1 files at r5, 1 of 1 files at r6, 2 of 2 files at r7, all commit messages.
Reviewable status: when planning a "properly curated" merge commit the PR must always be rebased onto latest master (waiting on @mwoehlke-kitware)

[jwnimmer-tri]

@drake-jenkins-bot mac-x86-monterey-clang-bazel-experimental-release please.

---

The https://github.com/RobotLocomotion/drake/blob/master/tools/workspace/README.md#semi-automated-monthly-upgrades document says:

Once the all Jenkins builds of the pull request have passed, additionally launch a macOS build, per

https://drake.mit.edu/jenkins.html#scheduling-an-on-demand-build

Once the macOS build passes, assign the pull request for review.

[jwnimmer-tri]

Reviewable status: 1 unresolved discussion, when planning a "properly curated" merge commit the PR must always be rebased onto latest master (waiting on @mwoehlke-kitware)

---

-- commits line 2 at r7:
The README instructions say "add the commit using the instructions that were printed by new_release". The commit instructions printed by the tool do not include the git commit sha in the subject like (e.g., for abseil_cpp_internal):

...
Done.  Be sure to review and commit the changes:
  git add tools/workspace/abseil_cpp_internal/repository.bzl
  git commit -m'[workspace] Upgrade abseil_cpp_internal to latest commit'

Since we need to rebase this PR anyway prior to merge, during the rebase we might as well remove the commit sha's from the three subject lines where it crept in. That will save the release manager the effort of editing them out later on.

[mwoehlke-kitware]

Reviewable status: 1 unresolved discussion (waiting on @jwnimmer-tri)

---

-- commits line 2 at r7:

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

The README instructions say "add the commit using the instructions that were printed by new_release". The commit instructions printed by the tool do not include the git commit sha in the subject like (e.g., for abseil_cpp_internal):

...
Done.  Be sure to review and commit the changes:
  git add tools/workspace/abseil_cpp_internal/repository.bzl
  git commit -m'[workspace] Upgrade abseil_cpp_internal to latest commit'

Since we need to rebase this PR anyway prior to merge, during the rebase we might as well remove the commit sha's from the three subject lines where it crept in. That will save the release manager the effort of editing them out later on.

The README also gives an example of what to do, which includes the new "version". Maybe that example should either be more complete, or should not exist. (Although, as the script knows how to make the commit, why doesn't it just do so?)

[jwnimmer-tri]

Reviewable status: 1 unresolved discussion (waiting on @mwoehlke-kitware)

---

-- commits line 2 at r7:

Previously, mwoehlke-kitware (Matthew Woehlke) wrote…

The README also gives an example of what to do, which includes the new "version". Maybe that example should either be more complete, or should not exist. (Although, as the script knows how to make the commit, why doesn't it just do so?)

Per f2f: yup, a command-line option to run the git commands on behalf of the user sounds find. That would reduce manual steps. (Users who are particular about how they invoke git could still commit manually.) In that case, the README could switch to use it, which would remove the misleading example commands.

[jwnimmer-tri]

This is just waiting on a rebase. Shall I push that on your behalf?

[mwoehlke-kitware]

Done. Didn't I already do that once, though? IIRC, usually someone with force-merge permission does the final rebase, because otherwise the rebase needs to be coordinated with said person actually doing the merge. (Or get lucky that CI completes without master changing out from under the PR.)

[jwnimmer-tri]

Didn't I already do that once, though?

Not since review was assigned, at least according to my interpretation of the github timeline.

IIRC, usually someone with force-merge permission does the final rebase, because otherwise the rebase needs to be coordinated with said person actually doing the merge.

That's probably a valid way to do it, but I don't know if we've ever done it that way. My advice is to do the rebase and then immediately ping one of the two super-admins (myself and Sherm) and we can override CI to merge immediately.

[mwoehlke-kitware]

(Rebased or not?) Huh. I could've sworn I rebased it when I removed the SHAs from the commit messages. Maybe I forgot to update my local master first. 😛

(Who rebases?) Hmm, I thought that was how it usually happened. Maybe I'm misremembering. 🤷

[mwoehlke-kitware]

-- commits line 2 at r7:

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Per f2f: yup, a command-line option to run the git commands on behalf of the user sounds find. That would reduce manual steps. (Users who are particular about how they invoke git could still commit manually.) In that case, the README could switch to use it, which would remove the misleading example commands.

(This thread is resolved. Also, see #18548.)

[jwnimmer-tri]

I wonder if GitHub has a "rebase this PR onto the tip of master" button on the web somewhere. That would probably be the easiest (especially if platform reviewers could just click it).

[mwoehlke-kitware]

Github has an option to rebase a PR. (I believe it doesn't create a merge commit, though, just adds the commits directly to master.)