And, there's a recent discussion about the maintainership for "orphaned package"s.
I totally agree with the bigger picture in this thread; spending (even minimal) effort on making releases to make packages sustain for longer period rather than letting packages fade out. Yes.
Below is something I just wanted to chime in to the thread, but decided not to because it's a little off-topic, and I was afraid that I may sound opposing to the main idea in the thread. while I am not. So I decided to tweet in my own space.
It was triggered by someone's line:
In my experience, running the `catkin_generate_changelog`, `catkin_prepare_release`, `bloom-release` commands takes up maybe 1% of the time in maintaining a package.As a release-maintainer of many long-lasting packages, I have to oppose here. So I just listed out the "release-maintainer"'s tasks I can think of, which may not be clear to the outside. These don't make a whole, and most of them may be optional, but still:
- Release the package.
- Changelog. Yes, `catkin_generate_changelog` populates raw commit logs per pkg.
- Totally optional, but I tend to spend certain amount of time to edit changelogs to be more useful than just a set of commit history.
- To what version to increment? Yes `catkin_prepare_release` handles this.
- But you want to version it "right", which requires some idea about backward compatibility, features added etc. Typically this might require coordinating developers and/or going through the commits/PRs that have been added.
- Run prerelease test.
- Locally if your repo doesn't do it on cloud (btw industrial_ci offers a feature to run it on cloud).
- For a ROS distro that supports multiple platform, run prerelease tests per each platforms if possible. For Kinetic, there was Wily until it went EOL, in addition to Xenial.
- `bloom` can fail for whatever issues in your packages that you are almost automatically in charge of fixing.
- Once issues occur on ROS buildfarm, a lot of times you're the only one to take (at least initial) action against it.
- Hence, `prerelease test`, folks.
- There's also "mental" responsibility. Not a big deal most of the times, but when something occurred like on buildfarm, you'd feel bad besides that it's you who people expect to fix the issues.
I do believe by doing the release chores more thoroughly like this, there's a benefit for the users. Still, what's critical at first hand is that the package being available, as discussed in the referenced thread and again I fully agree with that.