This is my personal opinion, and not the biggest problem facing the community these days, but one that seems easy to fix:
Once a GitHub repo reaches a relatively large number of contributors, the maintainers should use forks rather than branches prefixed with their username.
As an example, take rclcpp. There’s 72 branches. There’s 10 or so for the different ROS distros (rolling, humble, etc). Then there’s over 50 that appear to be from specific users. There’s also a bunch for features that I can’t immediately discern who’s in charge of.
When I click on the branches dropdown, I am usually looking for a specific distro branch, and it annoys me when I have to scroll through a ton of personal branches.
I definitely won’t defend my use of this for 80% of cases, but it does have real utility. When using CI systems, we disable builds on forks so that we don’t blow through our credits from random companies / users doing their usual thing. Having CI execute on feature development branches from maintainers can be helpful to generate metrics & validate changes work on another machine immediately (among others).
With that said, I admit that’s not remotely the main reason I do it (easy), but a useful side effect. I do cull branches off of the main project a couple times a year to make sure it doesn’t get out of control - but sometimes old branches of incomplete features may be useful for later revival and keeping it in ‘core’ keeps it visible.
With all that said, that’s maybe like 20% of cases and I’d begrudgingly follow the lead if that’s the way we wanted things to go for the 80% of un-exceptional cases.
While I agree to some degree, there is actually an extremely useful feature that using branches enables. Namely, the ability to specify that branch when running CI for the change in question.
If you have a change that spans rclcpp and rcl, and you name that branch the same on both, then running CI on it is a simple matter of filling out one field when running jobs on https://ci.ros2.org . If you are using forks, there are ways to achieve the same effect but it is more cumbersome; you almost always have to use some scripting to get it done reliably.
I understand that this feature is only available to the maintainers of a repository, but it is a useful feature, which is why we’ve kept this practice around for so long.
These are good points. I had assumed that in most cases, to get CI to run for the branch, you could just open a (draft) PR. I don’t have any experience with running CI across multiple repos and its unclear whether that is a limitation of ROS, Jenkins or Github.
