[Pulp-dev] release process updates

Sean Myers sean.myers at redhat.com
Mon Feb 6 20:08:35 UTC 2017


On 01/26/2017 12:25 PM, Sean Myers wrote:
> 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)

All of these are done, including the bonus task. I've additionally modified
the Redmine workflow to disallow transitioning issues to the VERIFIED state,
so anyone attempting the old workflow will be suitably stymied.

Note: I changed the "Requires QE Signoff" field name to "Verification Required".
If this change is hated, we can easily change it to anything else without breaking
any reporting.

-------------- 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/20170206/d0a6cfa9/attachment.sig>


More information about the Pulp-dev mailing list