Project

Profile

Help

Task #3131

closed

Create docs on a release preparation process

Added by bmbouter over 6 years ago. Updated about 5 years ago.

Status:
CLOSED - COMPLETE
Priority:
High
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
Yes
Tags:
Documentation, Pulp 2
Sprint:
Quarter:

Description

With a focus on Pulp3, Pulp2 (I think) is switching to be a feature-driven release. We don't have a documented, open way to organize when a release will occur and what is going into it. For now this will be scoped to Pulp2 since Pulp3 is still in alpha.

We will still use the same "release train" process which includes a release page on the wiki to track the release (like this one), but this will cause the "release train" to start in a request-driven way via an open process.

Let's post some ideas on this ticket, which can be aggregated into either a wiki doc or the pulp docs. Here are some starter questions:

What info is needed from developers to request the "release train" be started?
How much time notice is needed for release engineering to create a beta after it is requested?
What is the role of QE in requesting a "release train" to be started?
How will the request be sent, and how will it be acknowledged?
Where will this process be documented? Maybe In the Pulp2 docs or in a wiki page?

Actions #1

Updated by bmbouter over 6 years ago

What info is needed from developers to request the "release train" be started?

Three pieces of info: 1) Which plugin and/or core they want released. 2) If they are requesting a bugfix or feature release (z-stream or y-stream). 3) What the main feature/bugfix request is for (links to redmine tickets)

How much time notice is needed for release engineering to create a beta after it is requested?

I think release engineering should schedule the build no earlier than 1 week after the request. Having it scheduled a week out will allow other developers to wrap up other pieces of work to get it into the release. Details about which piece of work could be added to the release planning wiki page which would allow one document to keep everyone on the same page.

What is the role of QE in requesting a "release train" to be started?

QE can speak to their own role here.

How will the request be sent, and how will it be acknowledged?

The initial request via pulp-dev, including an ack sent back from release engineering declaring the scheduled build date. Further collaboration can happen on list but the release document in the wiki can act as a place to coordiante and plan also.

Where will this process be documented? Maybe In the Pulp2 docs or in a wiki page?

Where is our release train process documented currently?

Actions #2

Updated by pthomas@redhat.com over 6 years ago

Role of QE in release process is as follows.

Before beta build.

1. Help release engineering analyze test failures before the beta build.

After beta build before RC/GA
1. Perform upgrade testing
2. Verify any issues that are marked verification required

Actions #3

Updated by dalley over 6 years ago

  • Tracker changed from Issue to Task
  • % Done set to 0
Actions #4

Updated by bmbouter about 6 years ago

  • Status changed from NEW to CLOSED - COMPLETE
  • Assignee set to bmbouter

I forgot this issue was here. These docs got done even though it wasn't on a sprint: https://pulp.plan.io/projects/pulp/wiki/Pulp_2_Release_Planning I'm closing this issue as COMPLETE.

Actions #5

Updated by bmbouter about 5 years ago

  • Tags Pulp 2 added

Also available in: Atom PDF