Huge cleanup is upcoming about robots-configuration

[traversaro]

cc @nunoguedelha @S-Dafarra for the iCubGenova04 related development.

[traversaro]

Given that robots are shared resources amongst several lab members, to fork may not be practical, making more difficult for people to cooperate tuning the same robot.

Note that we can also have forks on shared group accounts, solving the cooperation problems. In the specific case, for iCubGenova04 we can create a branch on a fork in https://github.com/dic-iit .

To give another example of the fact that the situation is not so bad, take a look at the number of branches of this repo, compared to the number of forks (TL;DR 0).

"Ipse Dixit" is a well known and studied rhetorical trick. : )
Jokes apart, the advantages and disadvantages of having a lot of branches that are not used anymore can be discussed, and as all tech decisions, it will be always be a trade-off between relative merits.

Especially because the robots-configuration is a shared resource among different groups it is quite important that is really clear what is being important to have a clearly defined maintainer and policy on how stuff get eventually merged in the master branch. I understand the rationale of eventually having actively worked branches such as devel_iCubGenova04, but I fail to see what is the advantage of leaving around completely abandoned branches.

[pattacini]

Backup available at https://github.com/robotology-legacy/robots-configuration.

[S-Dafarra]

To be honest, I don't think the situation is so tragic. About 30 branches for a repo containing configuration files for 50+ robots is not too bad IMHO. I do agree it would be worth doing some cleanup of old stale branches, but to prevent creating new branches is a bit too drastic in my opinion.

Given that robots are shared resources amongst several lab members, to fork may not be practical, making more difficult for people to cooperate tuning the same robot.

After a long and not so smooth discussion inside our lab, we somehow agreed on having an integration branch devel_iCubGenova04 and create different branches to test other functionalities which may affect the normal functioning of the robot. I believe this is a good and common way to exploit git functionalities.

To give another example of the fact that the situation is not so bad, take a look at the number of branches of this repo, compared to the number of forks (TL;DR 0).

[pattacini]

@S-Dafarra I think you're looking only at your playground somehow 😉

Maintaining all the robots is our responsibility and the situation as such is definitely messy. This change aims to reduce this struggle. I apologize if it impacts your current workflow.

In this respect, Git is intrinsically distributed, hence forking is perfectly in line with its strategy. Therefore, one possibility for you is to fork devel_iCubGenova04 on https://github.com/dic-iit.

https://bitbucket.ihmc.us/projects/LIBS/repos/ihmc-open-robotics-software/branches does not represent our ideal workflow.

[S-Dafarra]

@S-Dafarra I think you're looking only at your playground somehow wink

Ouch 😅 Considering that out of the 18 branches (btw nice cleanup in 20 min 😄 ) 8 have been created by a member of our group, I would say this change affects especially my playground.

Maintaining all the robots is our responsibility and the situation as such is definitely messy. This change aims to reduce this struggle. I apologize if it impacts your current workflow.

Let me try to figure out the actual issue then. Sometimes we need to modify all the configuration files at once. I do see the mess then if there are tons of branches with scattered modifications. I agree this would not be sustainable. Let me know if I missed the point. What I am arguing is that preferring forks to branches does not prevent this problem, but it makes it worse. The difference would be that instead of having 18 branches, we would have 4-5 forks (to be optimistic), each with at least 3 branches (to be again very optimistic). I fail to see how this can be easier to handle.

Especially because the robots-configuration is a shared resource among different groups it is quite important that is really clear what is being important to have a clearly defined maintainer and policy on how stuff get eventually merged in the master branch. I understand the rationale of eventually having actively worked branches such as devel_iCubGenova04, but I fail to see what is the advantage of leaving around completely abandoned branches.

I completely agree with this. If things are well defined I don't see why we should prefer forks to branches.

[pattacini]

@S-Dafarra it's simply a matter of a clear identification of responsibility. Forks will fall under your responsibility, whereas branches are under our responsibility. I can ensure you that your current workflow won't be impacted after having established the fork.

[S-Dafarra]

I see. So it was not just for cleanup purposes 😉
I just hope that this shift of responsibility will not end up with sharp modifications of the repo without taking care of the actual status of the robots.

[pattacini]

@S-Dafarra removing stale branches that we're not responsible for is clearly a cleanup in my view. Perhaps you're not familiar with forks, and I can understand that you can be now a bit afraid of the policy change.

That said, any modification that this repository will undergo in the future will be applied having in mind the care for the users of all robots, yours as well as the other forty.

Hope this helps clarify what you thought was a risk to you.

[pattacini]

Just to be 100% sure that everything is crystal clear, with

I can ensure you that your current workflow won't be impacted after having established the fork.

I also meant that it'll be a shared responsibility to avoid that forks and upstream branches will diverge.

[pattacini]

As a reminder, @ale-git @julijenv you'll find your branches (not updated since > 7 months) backed up in https://github.com/robotology-legacy/robots-configuration/branches.