You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of PR #6 currently, @j-rivero has manually transcribed the dependency *.txt files from drake/setup/ubuntu into this repository's package.xml file, to match the currently-pinned version of Drake.
This is a fine way to bootstrap the work (and it's no problem to merge it to main that way), but for ongoing maintenance it is too costly & risky to keep doing that by hand. Before we finish this project, we'll need some kind of automation tooling that makes it easier (and safer) to upkeep the dependencies when switching to a newer pin of Drake, so that any Drake developer can perform the upkeep on a regular basis.
That could be a program that fully automates the process -- given the new version of Drake, it would read the *.txt files and rewrite the package.xml manifest with the new content. I'm not sure that the effort involved in writing a fully-automated tool would be worth it, though.
Instead, I imagine a better use of our time would be to write a tool that cross-checks the two lists, i.e., a linter. It would load both sets of data (the xml list, and the txt lists) and identify any dependencies that exist in one list but not the other, or are mis-categorized between build-time vs run-time dependencies. It could have some hard-coded list of special cases or heuristics, to help smooth over any differences. It would be run as a CI job, as a reminder for any pull requests to adjust what's necessary. The developer would still need to act on the report, either by editing the package.xml file or adjusting the heuristics.
In any case, that's just one idea. The bottom line is that we need the "upgrade drake version" process to be runnable by Drake developers, without needing any special skills.
The text was updated successfully, but these errors were encountered:
I'll also toss it in here since it's probably part of the same overall solution (tool and/or documentation) ...
We'll also need a CI lint check that the <version>1.26.0</version> in package.xml and the VCS_VERSION v1.26.0 in CMakeLists.txt are in sync. (Or alternatively, a tool that automatically changes both at the same time, in which case perhaps no linter is needed.)
We'll also need a CI lint check that the <version>1.26.0</version> in package.xml and the VCS_VERSION v1.26.0 in CMakeLists.txt are in sync. (Or alternatively, a tool that automatically changes both at the same time, in which case perhaps no linter is needed.)
As part of PR #6 currently, @j-rivero has manually transcribed the dependency
*.txt
files from drake/setup/ubuntu into this repository'spackage.xml
file, to match the currently-pinned version of Drake.This is a fine way to bootstrap the work (and it's no problem to merge it to
main
that way), but for ongoing maintenance it is too costly & risky to keep doing that by hand. Before we finish this project, we'll need some kind of automation tooling that makes it easier (and safer) to upkeep the dependencies when switching to a newer pin of Drake, so that any Drake developer can perform the upkeep on a regular basis.That could be a program that fully automates the process -- given the new version of Drake, it would read the
*.txt
files and rewrite thepackage.xml
manifest with the new content. I'm not sure that the effort involved in writing a fully-automated tool would be worth it, though.Instead, I imagine a better use of our time would be to write a tool that cross-checks the two lists, i.e., a linter. It would load both sets of data (the xml list, and the txt lists) and identify any dependencies that exist in one list but not the other, or are mis-categorized between build-time vs run-time dependencies. It could have some hard-coded list of special cases or heuristics, to help smooth over any differences. It would be run as a CI job, as a reminder for any pull requests to adjust what's necessary. The developer would still need to act on the report, either by editing the
package.xml
file or adjusting the heuristics.In any case, that's just one idea. The bottom line is that we need the "upgrade drake version" process to be runnable by Drake developers, without needing any special skills.
The text was updated successfully, but these errors were encountered: