From f875eb64a3aecd0dbdf20461c0c77f89a1cb1f4d Mon Sep 17 00:00:00 2001 From: Doug Hellmann Date: Wed, 16 Sep 2015 09:20:42 +0000 Subject: [PATCH] Adding Doug Hellmann candidacy for Release cycle management Change-Id: I7d67a612220452d1524a9f0faa4f24ef24c16213 --- .../Doug_Hellmann.txt | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 candidates/mitaka/Release cycle management/Doug_Hellmann.txt diff --git a/candidates/mitaka/Release cycle management/Doug_Hellmann.txt b/candidates/mitaka/Release cycle management/Doug_Hellmann.txt new file mode 100644 index 00000000..4427b794 --- /dev/null +++ b/candidates/mitaka/Release cycle management/Doug_Hellmann.txt @@ -0,0 +1,30 @@ +I am announcing my candidacy for PTL for the Release Management team +for the Mitaka release cycle. + +Although I only formally joined the release management team during the +Liberty cycle, I have been active in release-related activities for +much longer while serving as the PTL for Oslo. I worked with the +release and infrastructure teams to develop the release tools and +processes we use for Oslo libraries, and applying them to other +projects that now manage libraries. I am a core reviewer on the +requirements repository, and this cycle I started the work on +automating project releases using the new openstack/releases +repository. I was also involved in the process of moving server +projects away from date-based versioning to using quasi-semantic +versioning. Late in the Liberty cycle I started building reno, a new +release note management tool, based on some requirements we gathered +within the release team. + +My goal for the release team during Mitaka is to automate more of the +work with a review process that allows projects to be self-service, +with some lightweight oversight to manage release timing, version +numbers, and messaging. I would like to complete the work we have +started in the releases repository to allow project teams to ask for +releases at any point in the cycle, thereby encouraging them to shift +from a milestone-based to “intermediate” release model. Changing +release models will reduce the effort required to create a release by +removing some of the pressure to synchronize the activities of all +projects on milestones and make it easier to release more often, while +still giving us the benefits of stable branches for longer-term +maintenance of selected versions. Milestones can become guidelines, +rather than hard deadlines.