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
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,10 +19,10 @@ Having said that, for robots that are being used by many users of different rese
19
19
20
20
## 🔲 Fast-pace local workflow
21
21
Here's the outline of the workflow that aims to overcome/attenuate the users' headaches:
22
-
1. The organizational fork `icub-tech-iit/robots-configuration` is deployed on the robot system instead of the upstream repository `robotology/robots-configuration`.
23
-
2. We set up the machine user [`icub-tech-iit-bot`](https://github.com/icub-tech-iit-bot) on the robot system as the default committer with push access, but only locally to the repository. Push access is granted via a fine-grained PAT.
22
+
1. The organizational fork `mesh-iit/robots-configuration` is deployed on the robot system instead of the upstream repository `robotology/robots-configuration`.
23
+
2. We set up the machine user [`mesh-iit-bot`](https://github.com/mesh-iit-bot) on the robot system as the default committer with push access, but only locally to the repository. Push access is granted via a fine-grained PAT.
24
24
3. We enforce the use of `--author="Name Surnaname <user@email.com>"` command-line option (or the corresponding env variables) at commit time so that we can trace back who did what.
25
-
4. As a result, on the robot system, users will work and be able to push to the branch `icub-tech-iit/robots-configuration@devel` (actually, we will have robot-specific branches, see below). Some sort of push limitations will be enforced on this branch: e.g., no push force.
25
+
4. As a result, on the robot system, users will work and be able to push to the branch `mesh-iit/robots-configuration@devel` (actually, we will have robot-specific branches, see below). Some sort of push limitations will be enforced on this branch: e.g., no push force.
26
26
5. As it is paramount to enforce that at any time the configuration files allow the robot to start up flawlessly, there will be no specific automation aimed at synchronizing the upstream and the fork repositories back and forth. This process needs to be carried out under the supervision of educated humans.
27
27
1.**Human-supervised update fork → upstream**. It is performed periodically (e.g., every fortnight) via PR's. On the fork, the deal is that users will push only fixes (e.g., calibration values) and minor modifications (changing the options of some services) to the "official" robot files. Of course, users are free to deal with RL-specific additions/amendments. To facilitate integration, the PR's should be merged via `Rebase and Merge` to avoid this type of [problems](https://stackoverflow.com/questions/49200667/github-squash-and-merge-subsequent-pull-request-showing-all-previous-changes).
28
28
2.**Human-supervised update upstream → fork**. It is generally performed by iCub Tech developers (who keep on working upstream) when the time comes to perform tests on the robot. Once on the robot system, the developer will be using the fork, guaranteeing that the overall robot behavior won't be negatively affected by the latest modifications. Possible fixes pushed to the fork must be backed up upstream via PR's.
0 commit comments