<div dir="ltr">Do i understand correctly that blocker bugs will not be verified by default, unless we would set "require QE signoff" to True?<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 16, 2017 at 8:35 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Yes I think it captures the discussion. +1 to all ideas you've written.<br><br></div><div>[related ideas]<br></div><div>* The release criteria and workflow document is not community visible. Does it make any sense to move that to the wiki?<br></div><div>* 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.<br>* 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.<br></div><div>* After feedback is given, we should turn these into Redmine tasks (probably 3 tasks, 1 for each section).<br></div><div><br></div><div>Thanks for sending this out.<br><br></div><div>-Brian<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Jan 16, 2017 at 12:53 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>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.<br><br>Documentation Improvements<br>--------------------------<br><br>The <a href="https://mojo.redhat.com/docs/DOC-1101802" target="_blank">Pulp Release Criteria and Workflow</a> document appears to contain errors:<br><br>* The "Y Releases" section states that "Pulp issues addressed by the release must be verified." Otherwise, the release is blocked.<br>* It is not clear whether blocker bugs require verification.<br><br>These errors can be fixed like so:<br><br>* State that Y releases may be released even with bugs that haven't been verified. This is the same as for Z releases.<br>* State that blocker bugs do not require verification.<br> <br>Verification Tracking Improvements<br>------------------------------<wbr>----<br><br>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:<br><br>* Remove the VERIFIED state from issues.<br>* Add a 'verified' field to issues. Let this field be a boolean, and let it default to false.<br>* Remove references to the VERIFIED state from upstream and downstream automation.<br>* Remove references to the VERIFIED state from the docs, if present.<br><br>Verification Request Improvements<br>------------------------------<wbr>---<br><br>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 <a href="http://pulp.plan.io" target="_blank">pulp.plan.io</a> track this information:<br><br>* Add a 'require QE signoff' field to issues. Let this field be a boolean, and let it default to false.<br>* Expand release announcement emails. Let the emails include a link to a <a href="http://pulp.plan.io" target="_blank">pulp.plan.io</a> query that returns all issues requiring QE verification, and possibly copy-and-paste this list into the release announcement emails.<br><br>-----<br><br></div>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.)<span class="m_-6581084746968611883HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_-6581084746968611883HOEnZb"><font color="#888888">—Jeremy<br></font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>