Git Product home page Git Product logo

Comments (8)

AustinDeric avatar AustinDeric commented on June 29, 2024

I would like to see all the *_experimental repos be merged with the main repo. They should still be clearly identified This would allow us to:

  • save time
  • focus efforts on 1 repo
  • allow the experimental robots to be tested because the main repos get more use.

from abb_experimental.

gavanderhoorn avatar gavanderhoorn commented on June 29, 2024

Just a data point on the 'visibility' of (support) pkgs in experimental repositories: the pkgs in fanuc_experimental get about as much use as those in fanuc (judging by the nr of questions / support requests I receive about them), which I believe is mainly due to the fact that the ROS buildfarm indexes both repositories and both collections have ROS wiki pages (wiki/fanuc, wiki/fanuc_experimental) that also cross-reference each other.

I've recently submitted the abb_experimental repository for indexing by the buildfarm and created an initial wiki page for it as well (wiki/abb_experimental). Updating the abb_experimental metapackage to exec_depend on the appropriate pkgs should bring visibility of those on-par with the main repository.

from abb_experimental.

gavanderhoorn avatar gavanderhoorn commented on June 29, 2024

@Jmeyer1292 wrote:

The irb120, irb120t, and irb4400 have all been in this repository for > 2 years and should be transitioned to the main abb repo.

Should they first be updated to follow the ABB naming conventions?

from abb_experimental.

Levi-Armstrong avatar Levi-Armstrong commented on June 29, 2024

Should they first be updated to follow the ABB naming conventions?

I agree with updating them to the latest naming convention prior to transitioning them to the main repository.

from abb_experimental.

Jmeyer1292 avatar Jmeyer1292 commented on June 29, 2024

Well I look forward to reviewing the pull requests from the maintainers of this package!

from abb_experimental.

gavanderhoorn avatar gavanderhoorn commented on June 29, 2024

I think the visibility concerns for the packages in this repository have been addressed now that the ROS doc indexer has rebuilt everything today. See wiki/abb_experimental.

from abb_experimental.

AustinDeric avatar AustinDeric commented on June 29, 2024

Back to @Jmeyer1292's original comment, do we have requirements that need to be satisfied to move these robots to the main repo? Are there any measurable metrics?

from abb_experimental.

gavanderhoorn avatar gavanderhoorn commented on June 29, 2024

Are there any measurable metrics?

No, not at this time.

do we have requirements that need to be satisfied to move these robots to the main repo?

yes.

The point of having things in an experimental repository is that it allows the maintainers to make any potentially breaking changes without prior notice, that it allows for some soak time for new packages and to make them available to users to expose them to use-cases that are not necessarily those of the original author / maintainer.

After a certain amount of time packages stabilise and could be moved to the main repositories. At that point, the regular rules start to apply: semantic versioning, backwards-compatibility guarantees (tick-tock, etc) and all the rest.

Tbh I don't quite get what the problem is with this scheme. If it's lower visiblity then I believe we've addressed that with the creation of wiki/abb_experimental. If you take a look at the repository stats you'll see that that resulted in quite some traffic. My experience with fanuc_experimental is similar.

If it's the fact that experimental repositories are not released and have to be build from sources: I would say that anyone doing anything serious with ROS will have a workspace and runs Catkin once in a while anyway. With a proper .rosinstall and / or documentation it's peanuts to build the packages. But if we really want to we could create releases for the experimental repository as well.

The fact that #45, #53, #54, #56, #60, #63, #64, #65 and #67 were submitted -- and just for the few support pkgs that were contributed in the past few months -- I think shows that letting things sit here for some time is not such a bad thing.

Perhaps we could quantify what "a certain amount of time" is. That could take away some of the apparent 'arbitrary-ness' of when things do get migrated.

from abb_experimental.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.