Release Manager process proposal
- Dominant language
- Java
- Stars
- 14.9k
- Forks
- 3.5k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 88
Description
Proposals for improving the release manager process:
Release Manager Rotation
- Rotating Release Manager(s) for each release of Logstash
- Primary and assistant Release Manager - primary drives the release, follows the appropriate issue in dev (eg https://github.com/elastic/dev/issues/842), acting as point person for the release, following the steps on [the release guide](https://github.com/elastic/dev/blob/master/logstash/release.md)
- Assistant release is reviewer of code and CMS changes, and as a reminder if steps are not being followed, and also follows the dev issue
- On release day, assistant pushes the 'Publish' button
- The acting RM for each release should be clearly stated somewhere public - slack channel, for example
Meta issue for release steps for each release
- Create a checkpoint list of tasks, based on [the release guide](https://github.com/elastic/dev/blob/master/logstash/release.md). All checkboxes must be completed before the release is completed, and RM can be handed off to the Assistant.
I'd be happy to start this off either as Primary or assistant
Contributor guide
Research direction
Start by reading the release guide at logstash/release.md and the linked development issue, dev/issues/842. Compare the proposed rotation, checkpoint list, and public ownership details with the current process. Done would mean an agreed, documented release-manager workflow with clearly defined handoff and completion steps.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, release
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100