Add new release team for ROS 2 FlexBE

[dcconner]

• Name of the new release team: flexbe
• Release repositories to add:
  Submitted PR for naming review submit flexbe for ROS 2 naming review prior to creating release repos ros/rosdistro#37823

Proposed names of release repos:
url: https://github.com/ros2-gbp/flexbe_app-release.git
url: https://github.com/ros2-gbp/flexbe_behavior_engine-release.git

There are already a ROS 1 release repos created:
https://github.com/FlexBE/flexbe_app-release
https://github.com/FlexBE/flexbe_behavior_engine-release

But I planned to create separate ones on the ros2-gbp site .

I'm listing them below for completeness, but not sure we want to import versus just create new.

If there are any existing release repositories which should have their contents imported into the ros2-gbp organization, list and link to them here.
Leave the checkbox unchecked. The ros2-gbp administrator will check the box when they have completed the repository import.
-->

• flexbe_app

  • ros/rosdistro source entry
  • There is an existing release repository which should be imported: https://github.com/FlexBE/flexbe_app-release

• flexbe_behavior_engine

  • ros/rosdistro source entry
  • There is an existing release repository which should be imported: https://github.com/FlexBE/flexbe_behavior_engine-release

• Team members

  • @dcconner
  • @pschillinger

[nuclearsandwich]

I'm listing them below for completeness, but not sure we want to import versus just create new.

I think its entirely up to you. I'd propose either:

1. importing the existing release repo contents and using the ros2-gbp release repository for both Noetic and ROS 2 distributions. To prevent accidental pushes to the previous release repo it should be archived but not deleted.
   OR
2. starting fresh repositories in ros2-gbp and using them just for ROS 2 while using the current repositories for Noetic.

The advantages of the first option are that you don't have to worry about mistargeted pushes at the expense of slight confusion that "ros2-gbp" is used for ROS Noetic releases. But there's no technical reason not to do so.

I've opened #293 and will wait to merge it or import release repositories pending your preference above and the merging of ros/rosdistro#37823

[dcconner]

Would it be an option to combine by doing option 2, and then recreating the noetic release on ros2-gdp vs. importing the entire history. Then I can archive the old one after the changes take effect.

Otherwise, I'm inclined to just do option 2.

[dcconner]

@nuclearsandwich - Added rosdistro source link

[dcconner]

Is there anything missing that is preventing #293 from being merged so that I can prepare the release?

I have the naming approvals from rosdistro linked above:
* https://github.com/ros/rosdistro/blob/master/humble/distribution.yaml#L1541
* https://github.com/ros/rosdistro/blob/master/humble/distribution.yaml#L1551

[nuclearsandwich]

Would it be an option to combine by doing option 2, and then recreating the noetic release on ros2-gdp vs. importing the entire history. Then I can archive the old one after the changes take effect.

What reason is there not to import the Noetic history?
Importing it is a small effort, basically after I create the repository in ros2-gbp I just run

git clone --mirror $OLD_REPO 
cd $OLD_REPO
git remote add ros2-gbp [email protected]:$(basename $(pwd))
git push --mirror ros2-gbp

Keeping the release history for noetic together is a much nicer experience for someone who wants to review the release history of the package.

Is there anything missing that is preventing #293 from being merged so that I can prepare the release?

Nope with the links you mention we're now ready to proceed pending a decision on importing noetic history or starting fresh with ROS 2 releases only.

[dcconner]

I planned to import full history of noetic just not the obsolete branches Let's roll with this plan. Thanks.

[dcconner]

To clarify, my intent was to git push ros2-gbp noetic then create a new humble branch

If that is not sufficient and you want to mirror the entire repo with obsolete branches before noetic, let me know. I'd lean toward just doing option 2 in that case and only using this repo for ROS 2, but happy to comply with whatever you want to move this forward.

[dcconner]

@nuclearsandwich ?

[dcconner]

Touching base on this again.

There is an issue with flexbe_app release identified by @sloretz FlexBE/flexbe_app#90

I do NOT plan to push a flexbe_app release in the near term, but would like to get the humble release for flexbe_behavior_engine out the door.

[nuclearsandwich]

I planned to import full history of noetic just not the obsolete branches

Got it. Thanks for the clarification. I think that a --mirror clone even if it pulls in some older distros is going to be the most reliable way to make sure each ref for the noetic releases is included. It's also usually the ros2-gbp admin's responsibility to perform the initial mirror push and I'd prefer to to keep the practice limited to either mirror push or brand new repo rather than doing something in-between.

[dcconner]

Whatever you suggest to move this forward.

it's also usually the ros2-gbp admin's responsibility to perform the initial mirror push

I take "admin" to mean @nuclearsandwich or someone will handle the initial push then.

Let's just mirror the flexbe_behavior_engine-release.
The flexbe_app-release had issues, so we will start that one fresh at the appropriate time.

[nuclearsandwich]

#293 is being deployed now. Once it is I'll mirror flexbe_behavior_engine-release and report back here

I take "admin" to mean @nuclearsandwich or someone will handle the initial push then.

Yep that's generally me although there are others in case something happens to me.

[nuclearsandwich]

This change has been deployed and github.com/ros2-gbp/flexbe_behavior_engine-release mirrors https://github.com/FlexBE/flexbe_behavior_engine-release

[dcconner]

@nuclearsandwich questions:

1. why is the default branch of new mirrored repo not "master"
   It seems odd to have a very old branch as default and not show the release history
2. why do I not have permission to change the default branch settings?

[nuclearsandwich]

why is the default branch of new mirrored repo not "master"

This is a side effect of the fact that in git the 'default' branch is just the first one pushed. So when mirroring to an empty repository the first branch is often the lexicographically topmost one and thus becomes the default.

I've switched it to bloom's config branch which is master.

why do I not have permission to change the default branch settings?

Release team members have mantain permission on GitHub to protect from unintended or malicious deletion of community resources and ensure that repository configuration changes are managed via these terraform scripts.