Release Process! (ROLLING LIVE ON JAMMY) 🟢 🍯

[methylDragon]

[STATUS: RELEASED - LIVE ON JAMMY]

Buildfarm Status

• dev (ubuntu_jammy_amd64)
• doc (ubuntu_jammy_amd64)
• src (rhel_8)
• src (ubuntu_jammy)
• bin (ubuntu_jammy_amd64)
• bin (rhel_8_x86_64)
• bin (ubuntu_jammy_arm64)

Description

This issue tracks the status for the release of this repository into rosdistro and making it available for installation as .deb via the ROS 2 repositories.

It will detail the steps that need to be taken, and what recommended changes are good to have.

Highlights

• We need a LICENSE file.
• Some dependencies might be missing as well.
• Remember to create a new release tag to reflect the change.

Ok

• ament exports look ok

Release Process

Steps

• Add LICENSE file
• Reflect all system dependencies in package.xml (e.g. OpenCL), otherwise buildfarm builds will most likely fail, which means the package won't get released!!! (Remove extraneous dependencies #2)
  .
• Create a new release tag corresponding to the version specified in package.xml @vmayoral
• Create release repo (pending Add acceleration release team ros2-gbp/ros2-gbp-github-org#22)
• Create rolling and humble branches
• Wait for rosdistro merge of ament_vitis
• Do bloom release
  • bloom should PR rosdistro, if not, manually create a PR
  • vitis_common: 0.4.2-1 in 'rolling/distribution.yaml' [bloom] ros/rosdistro#32671
• rosdistro team to review package and merge PR (1-2 days, 1 month to get apt installable)
• Monitor build and release status on repo page and buildfarm

Recommendations

• You might want to add your email to the author tag on package.xml for consistency
• It'll be good if you can get the linters to run cleanly
• README.md with usage examples
• Tests
• Please namespace your code, especially if this package is intended to be used by many other downstream packages. See doc and associated google style doc, you'll prevent clashes that way

[methylDragon]

For specifying OpenCL's dependency, use the relevant rosdep key: ocl-icd-opencl-dev in package.xml

For information on which depends tag to use, see package.xml docs

[vmayoral]

You might want to add your email to the author tag on package.xml for consistency

797ea94

We need a LICENSE file.

fe1d4d1

Reflect all system dependencies in package.xml (e.g. OpenCL), otherwise buildfarm builds will most likely fail, which means the package won't get released!!!

6c07fb7, please assess @methylDragon and advise of any possible expected conflicts in the buildfarm.

[vmayoral]

Create a new release tag corresponding to the version specified in package.xml @vmayoral

f657a6c

It'll be good if you can get the linters to run cleanly

4f85bcd

Note however that Vitis default headers have been left as is for compatibility with https://github.com/Xilinx/Vitis_Libraries/. As indicated in the commit, the right approach in here would be to extract the headers from the Vitis_Libraries repository and into another one. Such repo should then apply linters appropriately and be integrated separated as a ROS 2 package.

This is a non-trivial effort (which I have not been able to achieve so far) that involves many teams in Xilinx. The changes above are the best trade-off I can come up but @methylDragon feel free to contribute on top if you feel there're bits that we want to include as well.

[vmayoral]

README.md with usage examples
Tests
Please namespace your code, especially if this package is intended to be used by many other downstream packages. See doc and associated google style doc, you'll prevent clashes that way

As for these, I see them as fantastic input but also as lower priority for various reasons: a) examples would require an extended documentation effort in combination with other packages (vitis_common is a library used by other modules), b) this library is meant to be used by embedded (Vitis) targets, so unless the buildfarm includes KV260 machines in the future, tests won't make much sense/run, c) i agree with the namespace suggestion, but this will require relevant changes in the headers to be implemented properly. Such an action would require alignment with other teams in Xilinx which may take time to reach.

[vmayoral]

I'm done from my side and think we're good in here @methylDragon but feel free to jump in an contribute with additions if you feel it necessary.

[methylDragon]

Change requested: 6c07fb7#commitcomment-69462085

[methylDragon]

I think with that one change, we should be good to go. 👍
I'm still trying to get the release repositories made.

[methylDragon]

Change PR made: #2

[vmayoral]

Merged changes.

[vmayoral]

New tag released.

[methylDragon]

Got it! Let's get rolling and humble branches, and we can go ahead with release!

[vmayoral]

Got it! Let's get rolling and humble branches, and we can go ahead with release!

Done.

[vmayoral]

bloom process fails so I think we need to wait until this gets enabled in rosdistro:

xilinx@xilinx:~/ros2_ws/src/xilinx/vitis_common$ bloom-release --rosdistro rolling --track rolling vitis_common --edit
ROS Distro index file associate with commit '725def91e71e2e1a9520416feb916c802ed75314'
New ROS Distro index url: 'https://raw.githubusercontent.com/ros/rosdistro/725def91e71e2e1a9520416feb916c802ed75314/index-v4.yaml'
Specified repository 'vitis_common' is not in the distribution file located at 'https://raw.githubusercontent.com/ros/rosdistro/725def91e71e2e1a9520416feb916c802ed75314/rolling/distribution.yaml'
Did you mean one of these: 'marti_common', 'ouxt_common', 'image_common'?
Could not determine release repository url for repository 'vitis_common' of distro 'rolling'
You can continue the release process by manually specifying the location of the RELEASE repository.
To be clear this is the url of the RELEASE repository not the upstream repository.
For release repositories on GitHub, you should provide the `https://` url which should end in `.git`.
Here is the url for a typical release repository on GitHub: https://github.com/ros-gbp/rviz-release.git
==> Looking for a release of this repository in a different distribution...
No reasonable default release repository url could be determined from previous releases.
Release repository url [press enter to abort]: https://github.com/ros2-gbp/ament_vitis-release.git
==> Fetching 'vitis_common' repository from 'https://github.com/ros2-gbp/ament_vitis-release.git'
Cloning into '/tmp/tmpwxqmz4ot'...
warning: You appear to have cloned an empty repository.
WARNING [vcstools] Command failed: 'git checkout master'
 run at: '/tmp/tmpwxqmz4ot'
 errcode: 1:
error: pathspec 'master' did not match any file(s) known to git
[/vcstools]
Creating 'master' branch.
Creating track 'rolling'...
Repository Name:
  <name>
    Name of the repository (used in the archive name)
  upstream
    Default value, leave this as upstream if you are unsure
  ['upstream']:
Upstream Repository URI:
  <uri>
    Any valid URI. This variable can be templated, for example an svn url
    can be templated as such: "https://svn.foo.com/foo/tags/foo-:{version}"
    where the :{version} token will be replaced with the version for this release.
  [None]: https://github.com/ros-acceleration/vitis_common.git
Upstream VCS Type:
  git
    Upstream URI is a git repository
  hg
    Upstream URI is a hg repository
  svn
    Upstream URI is a svn repository
  tar
    Upstream URI is a tarball
  ['git']:
Version:
  :{auto}
    This means the version will be guessed from the devel branch.
    This means that the devel branch must be set, the devel branch must exist,
    and there must be a valid package.xml in the upstream devel branch.
  :{ask}
    This means that the user will be prompted for the version each release.
    This also means that the upstream devel will be ignored.
  <version>
    This will be the version used.
    It must be updated for each new upstream version.
  [':{auto}']:
Release Tag:
  :{version}
    This means that the release tag will match the :{version} tag.
    This can be further templated, for example: "foo-:{version}" or "v:{version}"

    This can describe any vcs reference. For git that means {tag, branch, hash},
    for hg that means {tag, branch, hash}, for svn that means a revision number.
    For tar this value doubles as the sub directory (if the repository is
    in foo/ of the tar ball, putting foo here will cause the contents of
    foo/ to be imported to upstream instead of foo itself).
  :{ask}
    This means the user will be prompted for the release tag on each release.
  :{none}
    For svn and tar only you can set the release tag to :{none}, so that
    it is ignored.  For svn this means no revision number is used.
  [':{version}']:
Upstream Devel Branch:
  <vcs reference>
    Branch in upstream repository on which to search for the version.
    This is used only when version is set to ':{auto}'.
  [None]: rolling
ROS Distro:
  <ROS distro>
    This can be any valid ROS distro, e.g. indigo, kinetic, lunar, melodic
  ['rolling']:
Patches Directory:
  <path in bloom branch>
    This can be any valid relative path in the bloom branch. The contents
    of this folder will be overlaid onto the upstream branch after each
    import-upstream.  Additionally, any package.xml files found in the
    overlay will have the :{version} string replaced with the current
    version being released.
  :{none}
    Use this if you want to disable overlaying of files.
  [None]:
Release Repository Push URL:
  <url>
    (optional) Used when pushing to remote release repositories. This is only
    needed when the release uri which is in the rosdistro file is not writable.
    This is useful, for example, when a releaser would like to use a ssh url
    to push rather than a https:// url.
  :{none}
    This indicates that the default release url should be used.
  [None]:
Created 'rolling' track.
==> Testing for push permission on release repository
==> git remote -v
origin	https://github.com/ros2-gbp/ament_vitis-release.git (fetch)
origin	https://github.com/ros2-gbp/ament_vitis-release.git (push)
==> git push --dry-run
To https://github.com/ros2-gbp/ament_vitis-release.git
 * [new branch]      master -> master
==> Releasing 'vitis_common' using release track 'rolling'
==> git-bloom-release rolling
Processing release track settings for 'rolling'
Checking upstream devel branch 'rolling' for package.xml(s)
Cloning into '/tmp/tmpm_y0_m38/upstream'...
remote: Enumerating objects: 268, done.
remote: Counting objects: 100% (268/268), done.
remote: Compressing objects: 100% (174/174), done.
remote: Total 268 (delta 107), reused 249 (delta 90), pack-reused 0
Receiving objects: 100% (268/268), 541.96 KiB | 1.47 MiB/s, done.
Resolving deltas: 100% (107/107), done.
Looking for packages in 'rolling' branch... found 'vitis_common'.
Detected version '0.4.2' from package(s): ['vitis_common']

Executing release track 'rolling'
==> bloom-export-upstream /tmp/tmpm_y0_m38/upstream git --tag 0.4.2 --display-uri https://github.com/ros-acceleration/vitis_common.git --name upstream --output-dir /tmp/tmp0587xt8r
Checking out repository at 'https://github.com/ros-acceleration/vitis_common.git' to reference '0.4.2'.
Exporting to archive: '/tmp/tmp0587xt8r/upstream-0.4.2.tar.gz'
md5: ae60dc593cd2859b14c7a58aaed7baa6

==> git-bloom-import-upstream /tmp/tmp0587xt8r/upstream-0.4.2.tar.gz  --release-version 0.4.2 --replace
Creating upstream branch.
Importing archive into upstream branch...
Creating tag: 'upstream/0.4.2'
I'm happy.  You should be too.

==> git-bloom-generate -y rosrelease rolling --source upstream -i 1
Releasing package: ['vitis_common']
Releasing package 'vitis_common' for 'rolling' to: 'release/rolling/vitis_common'

==> git-bloom-generate -y rosdebian --prefix release/rolling rolling -i 1 --os-name ubuntu
Generating source debs for the packages: ['vitis_common']
Debian Incremental Version: 1
Debian Distributions: ['jammy']
Releasing for rosdistro: rolling

Pre-verifying Debian dependency keys...
Running 'rosdep update'...
ROS Distro index file associate with commit '725def91e71e2e1a9520416feb916c802ed75314'
New ROS Distro index url: 'https://raw.githubusercontent.com/ros/rosdistro/725def91e71e2e1a9520416feb916c802ed75314/index-v4.yaml'
Could not resolve rosdep key 'ament_vitis'
Failed to resolve ament_vitis on ubuntu:jammy with: Error running generator: Failed to resolve rosdep key 'ament_vitis', aborting.
ament_vitis is depended on by these packages: ['vitis_common']
<== Failed
Some of the dependencies for packages in this repository could not be resolved by rosdep.
<== The following generator action reported that it is missing one or more
    rosdep keys, but that the key exists in other platforms:
'['/usr/bin/git-bloom-generate', '-y', 'rosdebian', '--prefix', 'release/rolling', 'rolling', '-i', '1', '--os-name', 'ubuntu']'

If you are absolutely sure that this key is unavailable for the platform in
question, the generator can be skipped and you can proceed with the release.
Skip generator action and continue with release [y/N]? N

<== Error running command '['/usr/bin/git-bloom-generate', '-y', 'rosdebian', '--prefix', 'release/rolling', 'rolling', '-i', '1', '--os-name', 'ubuntu']'
Release failed, exiting.

[methylDragon]

Yep! ament_vitis has to get merged first!

[methylDragon]

I think ament_vitis needs another dependency added before it can build (which will then allow us to bloom this package).

ros-acceleration/ament_vitis#1

[vmayoral]

0.10.1 adds that as a dependency. Updated across all three branches.

[vmayoral]

Where are we in here @methylDragon, should we move forward with the bloom release?

[methylDragon]

We can't do the bloom release until the ament_vitis update gets merged into rosdistro, and the corresponding buildfarm job builds the binaries (which are currently failing), allowing rosdep to find ament_vitis as an installable dependency.

That is, we need ament_vitis to be an installable dependency since it's a dependency of vitis_common, so unfortunately we need to wait until the weekly batch merges before we can bloom this package :(

[vmayoral]

@methylDragon, should we go ahead and do the bloom release for this package now that ament_vitis binaries are passing?

[methylDragon]

I am doing the release now. RHEL will not be supported because ocl-icd-dev doesn't exist in the RPMs (only ocl-icd)

To rectify this, requires that the rosdep repos get updated, but I'm not sure if it makes sense because that'll require ocl-icd, which I think is a superset to be installed to get at ocl-icd-dev...)

So for now I will be skipping the release generation for RHEL.

[vmayoral]

All right, thanks!

[methylDragon]

ros/rosdistro#32671

[methylDragon]

Merged!

[methylDragon]

Closing this issue, since we're done 🎉
Congratulations on the press release too!