Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Intel RealSense team and repositories #297

Open
wants to merge 1 commit into
base: latest
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions realsense.tf
Original file line number Diff line number Diff line change
@@ -1,10 +1,12 @@
locals {
realsense_team = [
"doronhi",
"SamerKhshiboun",
"IntelRealSense",
"Nir-Az"
Comment on lines +3 to +5
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to change team members, can you please provide links to the relevant package.xml <maintainer> tags in the source repository for these individuals or otherwise provide a link demonstrating that they are authorized maintainers/releasers of these ROS packages.

Copy link
Author

@SamerKhshiboun SamerKhshiboun Jul 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

]
realsense_repositories = [
"librealsense-release",
"ros2_intel_realsense-release",
"librealsense2-release",
"realsense-ros-release",
Comment on lines -6 to +9
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these "renames" of the current release repositories or the addition of two repositories and the removal of two others?

Release repositories cannot be deleted so the old repositories must be archived rather than removed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these "renames" of the current release repositories or the addition of two repositories and the removal of two others?

Release repositories cannot be deleted so the old repositories must be archived rather than removed.

Renaming of the old release repositories. The new ones links:
https://github.com/IntelRealSense/librealsense2-release
https://github.com/IntelRealSense/realsense-ros-release

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renaming of the old release repositories. The new ones links:

I think that we may be miscommunicating, IntelRealSense/librealsense2-release does not appear to have any common commits from the master branch (bloom's central config branch) of ros2-gbp/librealsense-release which suggests to me that this is a new release repository and not an extension of ros2-gbp/librealsense-release.

The same is the case for ros2-gbp/ros2_intel_realsense-release and IntelRealSense/realsense-ros-release

I think the right thing to do is:

  1. Archive both
  • ros2-gbp/librealsense-release
  • ros2-gbp/ros2_intel_realsense-release
  1. and then create new ros2-gbp repositories:
  • ros2-gbp/librealsense2-release
  • ros2-gbp/realsense-ros-release
  1. and mirror push the current contents of the IntelRealSense hosted repositories:
  1. finally, once we've verified that you can push releases to the ros2-gbp repositories it's a good idea to archive the ones in IntelRealSense to avoid accidentally pushing to them in the future.

If that plan works for you, let me know and I'll refactor this PR to include the archivals and mirror the current repositories.

Copy link
Author

@SamerKhshiboun SamerKhshiboun Jul 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @nuclearsandwich,

Thanks for the detailed solution you are proposing.
Before doing the steps above, I need some clarifications from your side:

  • How this is going to affect current/old release for the different distros ? (humble, iron, and even EOL distro.. foxy, galactic...)
  • What about writ access to gbp repo ? will we have the permissions to write/edit patches and files of our releases ?
  • How does this change will affect our future releases ? specially when new ROS distros are out

Thanks,
Samer

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How this is going to affect current/old release for the different distros ? (humble, iron, and even EOL distro.. foxy, galactic...)

Archiving the repositories will make them read-only but keep them available for people using those earlier packages.

What about writ access to gbp repo ? will we have the permissions to write/edit patches and files of our releases ?

Release repositories are generally not modified by hand, the bloom release tool is primarily used to update release repositories based on changes in the upstream source repository.

How does this change will affect our future releases ? specially when new ROS distros are out

The release process is the same for most ROS 2 packages. Once granted access to the ros2-gbp repositories you'll be able to follow http://docs.ros.org/en/rolling/How-To-Guides/Releasing/Subsequent-Releases.html when making releases.

]
}

Expand Down