[Pulp-dev] release process updates

[Sean Myers]

On 01/16/17 12:53, Jeremy Audet wrote:
> 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
> errors:
> 
> * 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
> automation.
> * 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.


Unless there are objections, I plan to make the changes above to Redmine
next week. Specifically, I plan to:

- Create a new field in Redmine: "Require QE Signoff" boolean (checkbox, default
  False)
- Create a new field in Redmine: "Verified" boolean (checkbox, default False)
- Get bonus points for retroactively setting the "Verified" flag on existing
  issues that had status "VERIFIED" before moving to "CLOSED"
- Update release reports (Next Bugfix Release & Next Feature Release) to
  include "Required QE Signoff" column
- Add a new Redmine report to display all issues that require QE signoff
  (probably grouped by platform release version)

Some concerns have been raised regarding whether or not certain issues, such
as refactors or identified blockers, should automatically require. I think we
agree that we can make those changes later if needed, and that adding these
fields to Redmine does not prevent us from making those changes if and when
we choose. For example, if we want all blocking issues to require verification,
we can make part of the blocker filing process be to check the "require QE
signoff" box; the process is independent of this reporting change.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170126/ea417c4d/attachment.sig>