Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade Externals January 2023 #18510

Closed
BetsyMcPhail opened this issue Jan 3, 2023 · 3 comments
Closed

Upgrade Externals January 2023 #18510

BetsyMcPhail opened this issue Jan 3, 2023 · 3 comments
Assignees
Labels
component: build system Bazel, CMake, dependencies, memory checkers, linters

Comments

@BetsyMcPhail BetsyMcPhail added the component: build system Bazel, CMake, dependencies, memory checkers, linters label Jan 3, 2023
@jwnimmer-tri
Copy link
Collaborator

As part of this work, could I ask you to also PR a related documentation change? (Could be the same PR, or a separate one; either is fine by me).

Here's my rough draft of the change. In short, for failed upgrades we should track those using a WIP PR in lieu of a standalone issue. A pull request will make the nature of the failure (and the code required to repro the failure) much more clear than an issue.

--- a/tools/workspace/README.md
+++ b/tools/workspace/README.md
@@ -107,9 +107,13 @@ For any non-trivial changes (i.e., changes that go beyond changing version
 numbers, checksums, or trivial fixups to patch files or code spelling), do not
 attempt to fix the problems just because you are accountable for the routine
 upgrade procedure every month. As a rule of thumb, if you need to spend more
-than 5-10 minutes on an upgrade, you should defer the work to a separate issue:
+than 5-10 minutes on an upgrade, you should defer the work to a separate pull
+request:
 
-* open an issue about the need for an upgrade of that one specific external;
+* open a pull request with the WIP patch for that one specific external;
+
+* entire that the Jenkins output shows the problem (e.g., trigger any extra
+  non-default builds that failed);
 
 * assign it to the feature owner associated with that external (to find out who
   that is, ask for help in the drake developers ``#build`` slack channel); and

@jwnimmer-tri
Copy link
Collaborator

As part of this work, could I ask you to also PR a related documentation change? ...

For the record, this was completed in #18517.

@jwnimmer-tri
Copy link
Collaborator

To my reading, all of the January upgrades have either been merged already, or filed as distinct issues. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: build system Bazel, CMake, dependencies, memory checkers, linters
Development

No branches or pull requests

3 participants