Yes, that is my understanding. On Wed, Jan 18, 2017 at 12:39 PM, Ina Panova <[email protected]> wrote:
> 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 <[email protected]> > 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 <[email protected]> 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 >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
