Opensource software package maintenance in a cleaner, more thorough and verbose manner

There's various form of maintenance for software packages. ROS wiki spreads out well.
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.

For larger set of packages, making a new release could take up some good time if done thoroughly (at least it does for me). But for doing things like above, only changelog is where volume matters, so releasing in a good manner is non trivial IMO.

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.