[Pulp-dev] release process updates

[Ina Panova]

Do i understand correctly that blocker bugs will not be verified by
default, unless we would set "require QE signoff" to True?




--------
Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Mon, Jan 16, 2017 at 8:35 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> Yes I think it captures the discussion. +1 to all ideas you've written.
>
> [related ideas]
> * The release criteria and workflow document is not community visible.
> Does it make any sense to move that to the wiki?
> * For the two new fields proposed, they should apply to Redmine tracker
> types (Story, Issue, and Task but not Refactor). Refactors cannot be
> "verified" or "require QE signoff" because by definition they should
> perform.
> * For mailing list proposals with feedback, what about a time limit.
> Perhaps 1 week? If there are no -1s given by Jan 24th, we could consider
> this proposal accepted.
> * After feedback is given, we should turn these into Redmine tasks
> (probably 3 tasks, 1 for each section).
>
> Thanks for sending this out.
>
> -Brian
>
> On Mon, Jan 16, 2017 at 12:53 PM, Jeremy Audet <jaudet at redhat.com> 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.
>>
>> -----
>>
>> 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
>> useful.)
>>
>> —Jeremy
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170118/d862ce6e/attachment.htm>