[Pulp-dev] release process updates

Jeremy Audet jaudet at redhat.com
Mon Jan 16 17:53:16 UTC 2017

This email is a follow-up to today's "Release process and communication."
The goal of today's conversation was to improve how the dev and QE teams
interface. The following proposals were made.

Documentation Improvements

The Pulp Release Criteria and Workflow
<https://mojo.redhat.com/docs/DOC-1101802> document appears to contain

* The "Y Releases" section states that "Pulp issues addressed by the
release must be verified." Otherwise, the release is blocked.
* It is not clear whether blocker bugs require verification.

These errors can be fixed like so:

* State that Y releases may be released even with bugs that haven't been
verified. This is the same as for Z releases.
* State that blocker bugs do not require verification.

Verification Tracking Improvements

There should be some way for QE to state that an issue has been verified.
QE currently does this through the VERIFIED state, but this is problematic:
issues are changed to a CLOSED state when bugs are released, effectively
erasing QE's stamp of approval. The proposed solution is to update how
redmine tracks issues:

* Remove the VERIFIED state from issues.
* Add a 'verified' field to issues. Let this field be a boolean, and let it
default to false.
* Remove references to the VERIFIED state from upstream and downstream
* Remove references to the VERIFIED state from the docs, if present.

Verification Request Improvements

The developers should have some mechanism to require that an issue be
verified before a release goes out the door. This mechanism should be
present because most releases are not blocked based on whether or not QE
has verified an issue. The proposed solution is to let pulp.plan.io track
this information:

* Add a 'require QE signoff' field to issues. Let this field be a boolean,
and let it default to false.
* Expand release announcement emails. Let the emails include a link to a
pulp.plan.io query that returns all issues requiring QE verification, and
possibly copy-and-paste this list into the release announcement emails.


Does this capture the actionable topics from today's discussion? Do you
agree with these proposals, or not? (Even a simple "Yes, and yes." is

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170116/c3ff84a6/attachment.htm>

More information about the Pulp-dev mailing list