Migration of staubli_val3_driver to its own repository

[gavanderhoorn]

As a consequence of the consensus reached in ros-industrial/ros_industrial_issues#49, I've extracted staubli_val3_driver out of this repository and have created a new repository that hosts just the driver. You may find it at ros-industrial/staubli_val3_driver.

I've tried to retain as much of the commit history as possible (and where it made sense), and have transferred open issues as well.

As this package is largely ROS-agnostic (it essentially hosts a VAL3 application and some launch files), I've only created a master branch.

Commits and file provenance have been retained, and references to issues and PRs have been updated wherever possible.

What remains is to remove staubli_val3_driver from this repository here.

I don't want to do that unannounced, so this is the announcement -- at least here on the tracker.

Rationale for doing this now (and with this package): @marshallpowell97 is working on some improvements and will be contributing PRs to fix some of the outstanding issues. As his work is mostly focused on the driver, and the history of staubli_val3_driver was mostly linear, I decided to extract it before @marshallpowell97's changes would have to be integrated.

[gavanderhoorn]

If any of the current users feel it's not a good idea to separate the driver from this repository, you have till 2020-01-23 to comment here and provide some rationale.

On 2020-01-24 I will git rm -r staubli_val3_driver from this repository.

Nothing else will change, so previous commits and history of staubli_val3_driver will be retained here. If you currently have a fork of staubli_experimental with changes to staubli_val3_driver you will still be able to relate those to the state in this repository (even after the removal of the package).

[gavanderhoorn]

@marshallpowell97: I realise this will complicate your work somewhat, as you should fork the new repository and migrate your commits.

Let me know if you'd like me to assist you with this.

[marshallpowell97]

@gavanderhoorn Should be no problem. I like the idea of having a separate repo. I won't be able to add any more to my fork until next month (busy time of the year for us), but I can go ahead and migrate my commits and submit a PR.

[gavanderhoorn]

Submitting a PR would be good, as it would allow us to discuss the approach(es) you've taken.

I would encourage you to do that.

---

Edit: and just to be extra clear: a PR against the new repository :)

But don't throw away your old fork yet. It may be that there is some community member which has a very strong argument for not migrating the driver to its own repository.

[marshallpowell97]

Would it be okay to have all the changes in a single commit, or is it preferred to have each individual change in its own commit?

[gavanderhoorn]

I would actually prefer to have logical, coherent sets of changes in separate commits. So not necessarily individual changes, but also not everything in one large one.

That would facilitate both review as well as management of changes.

A good heuristic I sometimes use is to keep a working system in mind and think about how a set of changes would affect it: one way to then structure commits would be to keep the system in a working state at all times (fi: introduce a new feature/function in one commit and then start using it in a follow-up one). This is of course not always possible and neither does it always make sense, but it does work quite well for certain kinds of changes.

Another guideline would be to never move and edit files (ie: their content) in the same commit. It becomes impossible to revert the move and/or the content changes separately.

There are more, but it's rather off-topic for this issue.

---

Edit: appreciate you asking btw.

[marshallpowell97]

Awesome, I will submit the PR tomorrow once I have everything migrated.