I’m not sure I completely understand why we should not be having QE verify Refactors. What if we’re worried about introducing regressions with a Refactor?
David On Mon, Jan 16, 2017 at 2: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
