Create new makefile targets for release management.
- ``release-create-issue``: Automates creating a release checklist - https://github.com/jmchilton/galaxy/issues/41)
Check list contains actual tailored ``make`` commands and links (for PRs and issues).
- ``release-check-metadata``: Checks milestone PRs for required metadata needed for generating bootstrapped release notes.
` ``release-bootstrap-history``: Bootstrap release notes from PRs and metadata.
- ``release-check-blocking-prs``: Check for PRs blocking release, should happen before branching release and before tagging release.
- ``release-check-blocking-issues``: Check for Issues blocking release, should happen before tagging release. (Only allowed issue is the release creation issue.)
The issue created with ``release-create-issue`` documents how and when to execute subsequent ``make`` targets (including the target to create the issue for the next release).
This PR contains a bunch of other enhancements to the bootstrap_history.py script to enable these targets and renames ``create_release_rc`` Makefile target so all release related targets start with the prefix ``release-``.
Conflicts:
Makefile
Marius has been an indispensable member of the Galaxy community for a while - his contributions to tools, planemo, and ansible roles have been signficant and invaluable.
However over the last several months he has taken a very active role on the Galaxy central code base itself. He has worked through a number of very intricate bugs to tool shed, tooling, and workflow code - consistently providing high quality and important bug fixes. Beyond that he has made signficant enhancements to the testing of Galaxy and workflow available to tool developers leveraging local tool sheds. He also is very active in the review of issues and pull requests, perhaps the most important role of Galaxy committer group members.
Ross Lazarus has done a lot for Galaxy for a long time and has been a fantastic presence in the community. He is now retired and has no intention of touching the code or reviewing pull requests so I think it is best to remove him from the committers list. I have contacted him to confirm this and he has no problem with his removal from this group.
Just to reiterate, this isn't a condemnation of any kind, from the organization policies - "Periodically, active members may review this group and request inactive members are removed - this should not be interpreted as a condemnation of these inactive members but merely as a reflection of a desire to keep this group focused enough to remain effective."
Dannon Baker