<div dir="auto">I personally would be -1 then( to this point ), because if we state that we cannot make release with blokers opened, that would be not really wise to make the actual release without their verification. How can we state that the blocker was fixed and in addition what's then the point then to make the issue as blocker and fix it in tight deadlines. <div dir="auto">I think all blocker bugs should be verified by default, and other bugs just when there's flag set by devs. </div></div><div class="gmail_extra"><br><div class="gmail_quote">18 янв. 2017 г. 19:23 пользователь "Brian Bouterse" <<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a>> написал:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, that is my understanding.<br></div><div class="elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 18, 2017 at 12:39 PM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@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">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="m_2326157126863671707m_-7967116820162415899gmail_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><div><div class="m_2326157126863671707h5">
<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="m_2326157126863671707m_-7967116820162415899h5">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="m_2326157126863671707m_-7967116820162415899h5"><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_2326157126863671707m_-7967116820162415899m_-6581084746968611883HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_2326157126863671707m_-7967116820162415899m_-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" 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></div></div>
</blockquote></div><br></div>
</div></blockquote></div><br></div>