Announcing the OSRF Project Committee for Infrastructure

Although not commonly thought about, except when something breaks, the infrastructure provided by the OSRF for the developer and user communities is an integral part of all our other projects. It provides the build farm used to compile and prepare the binary packages, the computing power for continuous integration (both the manual kind and the Rpr automatic kind), and the management of many of the websites that help the community to collaborate.

Until the end of last year, this infrastructure was managed and payed for almost exclusively by the Open Source Robotics Corporation, funded by its engineering consulting activities. That all changed when OSRC was acquired by Intrinsic, leaving the OSRF behind. In the few months since then the OSRF has been working with former OSRC engineers to transition the infrastructure management into a core OSRF activity, as well as hiring two dedicated engineers to work on buildfarm maintenance activities. Although those engineers are amazing, it’s a cut from the amount of on-staff engineering time OSRC had dedicated to infrastructure-related activities. The OSRF has been relying on volunteers (primarily former OSRC engineers now at Intrinsic, for which we are very grateful to Intrinsic for providing their time) to fill in the gaps in staffing and keep the infrastructure ticking over.

Obviously this is not a satisfactory long-term situation, and for that reason the OSRF would like to have more community involvement in maintaining and improving the infrastructure we all depend on. As part of achieving this, the OSRF is starting a new Project Committee for Infrastructure.

The PC for Infrastructure’s initial responsibilities will primarily be:

  • management of the OSRF Infrastructure;
  • management of committer access rights to infrastructure-related repositories;
  • setting and managing project policies (requirements for pull requests, etc.);
  • identifying how to improve the infrastructure and managing the implementation of those improvements; and
  • Helping respond to incidents, in conjunction with OSRF staff.

The PC will be comprised of:

  • OSRF CTO or their designated representative, for oversight;
  • committee chair, appointed by OSRF;
  • project committers; and
  • representatives of other OSRF projects.

The Chair is responsible for running the project, organising the Project Committee meetings, and making regular activity reports (including to the wider ROS community). Project committers are those people who have earned the right to merge changes into the code used by the infrastructure and make changes to the infrastructure itself. They contribute to discussion on design and implementation decisions, and in general help to maintain and develop the infrastructure day-to-day. Project Committers are the decision-makers of the project. New Project Committers are appointed by the Chair at the recommendation of existing Project Committers. Project Committers are required to demonstrate continued participation in the project.

The PC for Infrastructure will be chaired by Steven! Ragnarök, formerly at OSRC, where he lead the Infrastructure team, and now at Intrinsic. The following additional people have agreed to be on the PC.

  • Jose Rivero, project committer
  • Scott Logan, project committer
  • Cristobal Arroyo, project committer
  • Jorge Perez, project committer
  • Clara Berendsen, project committer
  • Chris Lalancette, ROS representative
  • Addisu Taddese, Gazebo representative
  • Michael X Grey, Open-RMF representative

We look forward to the PC for Infrastructure getting to work making the lives of ROS, Gazebo and Open-RMF users and developers easier.

If you are interested in helping out with the OSRF Infrastructure, please get in touch with myself or with Steven!. In addition to technical contributions, we will also have additional ways for the community to help out with the infrastructure in the near future.


Geoff Biggs
CTO, Open Source Robotics Foundation

13 Likes

Thank you very much @gbiggs for the introduction of this very important part of the OSRF. I consider a functional infrastructure the backbone of all of ROS. The major part of the success of ROS in distribution but also the quality of the developer’s workflow relies heavily on this infrastructure.

But, could you please clarify two things:

  1. What are “infrastructure-related repositories”? How and where are those defined. I assume everything under ros-infrastructure · GitHub would be a good start, but what would be the process to add or remove repos there?
  2. What is the intended way for members of to interact with the PC? How can they contribute requirements and how is this moderated?

Thank you @gbiggs for your efforts getting our committee up and running!

Right now, the infrastructure project is predominantly focused on helping the Foundation transition to its new structure and building out the technical framework and knowledge base for sharing operational responsibility and our bandwidth for other activities is extremely limited. That work is both highly sensitive and timing critical and so the profile of community contributions has been different, and will continue to be for the next couple of months, than what I hope to achieve long term.

In addition to keeping the web and build infrastructure running smoothly, which like any set of web services requires constant upkeep, proactive maintenance, and occasional incident response, we are also helping the OSRF’s projects with platform support. Most recently ROS 2 Rolling (and thus the upcoming Iron release) has successfully transitioned its target RHEL platform from RHEL 8 to RHEL 9 and we are preparing to add support for Debian Bookwork to the ROS bootstrap layer of packages. We are also looking ahead to next year already, as the work to prepare ROS and Gazebo for Ubuntu 24.04 starts this summer and picks up heavily in the fall after the 23.10 release.

As the transition work draws to a close, we’ll also start working on the first public Infrastructure roadmap for OSRF projects and infrastructure community meetings. Those meetings will be announced here and on the Gazebo Community discourse as well. In the meantime you can find us in the GitHub issues and pull requests doing infrastructure work, here on Discourse, and on the OSRF community discord in the Infrastructure related channels.


There is not a current complete inventory, and there are a good number of repositories which overlap between infrastructure and the Foundation’s other project teams and which are spread across multiple organizations. The gazebo-tooling organization also includes a number of important infrastructure related repositories as does the osrf organization itself. Any project which is critical for the continuing delivery and developer experience for OSRF projects will have some amount of participation from Infrastructure, just as they always have.

ROS has always been a federated ecosystem, and with a few exceptions to support automation, there has never been a requirement that repositories be housed in specific organizations (or even on GitHub at all) in order to be part of the infrastructure. Depending on what you are looking to do, I’d suggest just setting up a repository under your own namespace and sharing it with the community on Discourse.

The Infrastructure team within Open Robotics has been meeting weekly for several years and we’ve had a couple of office hours events which were open to the public.
With the new project committee structure I want to increase the community participation opportunities, borrowing even more from the Gazebo community meetings structure.

Project Committee meetings will likely remain invite-only, but we will also be expanding the scope of the community reviewer role and including them in the project committee going forward.

I’m not quite sure what you mean here. Are you asking how the community can contribute changes which fulfill outstanding infrastructure requirements and goals or how the community can add requirements to the infrastructure team’s roadmap?

3 Likes

While both are of cause valid points, I think the contribution of sw changes is pretty clear. I was more interested in how the community can contribute requirements or how changes in the underlying assumptions are handled. Especially for smaller aspects that may not be worth to cover in a rep.

For now, I’d suggest the same procedures that have always been available: pull requests, issues, and discussions on discourse.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.