Comments (11)
cc @nunoguedelha @S-Dafarra for the iCubGenova04 related development.
from robots-configuration.
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.
from robots-configuration.
Backup available at https://github.com/robotology-legacy/robots-configuration.
from robots-configuration.
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).
from robots-configuration.
@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.
from robots-configuration.
@S-Dafarra I think you're looking only at your playground somehow wink
Ouch
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.
from robots-configuration.
@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.
from robots-configuration.
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.
from robots-configuration.
@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.
from robots-configuration.
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.
from robots-configuration.
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.
from robots-configuration.
Related Issues (20)
- Encoder Consistency test - hip pitch joint gear ratio HOT 5
- Update joint limits iCub3 HOT 5
- Inconsistencies of joint names HOT 2
- Robot with XSens MT IMU in waist still spawn the IMU YARP Hardware Device via inertial instead of separating hardware and Network Wrapper Servers HOT 3
- Document attach/detach levels used for different kind of devices
- Unintended change of frequency of iCub's controlBoard_nws_yarp instances from 100 Hz to 50 Hz HOT 4
- `controlboardwrapper2` deprecation HOT 5
- `grabberDual` device removal in YARP 3.8.0 HOT 8
- Migration of all icub xml files to the new yri syntax HOT 1
- Replace `embObjInertial` w/ `embObjIMU` – Stint 1 HOT 20
- `inertial` device removal in YARP 3.8.0 HOT 5
- Implement `dry-run` test in the CI HOT 20
- Replace `analogServer` with `multipleanalogsensorsserver` for publishing FT data – Stint 1 HOT 6
- `batteryWrapper` device removal in YARP 3.8.0 HOT 2
- Fix Dry-Run errors HOT 35
- Replace `analogServer` with `multipleanalogsensorsserver` for publishing FT data – Stint 2 HOT 8
- ergoCubSN000: expose BMS on YARP network via `battery_nws_yarp` HOT 1
- CI failing on `ergoCubSN000` and `iCubGenova09` with the latest `yarp-3.8` HOT 11
- Missing example for `embObjMultipleFTsensors` device in `iCubTemplates/iCubTemplateV6_0/hardware/FT`
- Split robots between `maintained` and `unmaintained` and refactor CI dry-run accordingly HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from robots-configuration.