<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 9:28 PM Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 9:04 PM Shyam Ranganathan <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/03/2018 11:32 AM, Pranith Kumar Karampuri wrote:<br>
> <br>
> <br>
> On Wed, Oct 3, 2018 at 8:50 PM Shyam Ranganathan <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br>
> <mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>>> wrote:<br>
> <br>
> On 10/03/2018 11:16 AM, Pranith Kumar Karampuri wrote:<br>
> > Once we have distributed tests running, such that overall<br>
> regression<br>
> > time is reduced, we can possibly tackle removing retries for<br>
> tests, and<br>
> > then getting to a more stringent recheck process/tooling. The<br>
> reason<br>
> > being, we now run to completion and that takes quite a bit of<br>
> time, so<br>
> > at this juncture removing retry is not practical, but we<br>
> should get<br>
> > there (soon?).<br>
> ><br>
> ><br>
> > I agree with you about removing retry. I didn't understand why recheck<br>
> > nudging developers has to be post-poned till distributed regression<br>
> > tests comes into picture. My thinking is that it is more important to<br>
> > have it when tests take longer.<br>
> <br>
> Above is only retry specific, not recheck specific, as in "we can<br>
> possibly tackle removing retries for tests"<br>
> <br>
> But also reiterating this is orthogonal to the lock down needs discussed<br>
> here.<br>
> <br>
> <br>
> As per my understanding the reason why lock down is happening because no<br>
> one makes any noise about the failures that they are facing as and when<br>
> it happens, and it doesn't get conveyed on gluster-devel. So is there<br>
> any reason why you think it is orthogonal considering it is contributing<br>
> directly to the problem that we are discussing on this thread?<br>
<br>
Taking steps to ensure quality is maintained is going to reduce<br>
instances of lock down, hence orthogonal.<br></blockquote><br><div>Purpose of my responses has been to prevent a lock down because I believe the existing process of locking down the complete branch doesn't change behaviors of developers to prevent a lock down. The process seems to reinforce it. Hence I raised it on this thread, because it is contributing to it. It doesn't look like the discussion went to a logical end. I still don't know what are the new actions we are taking to prevent lock down from happening. What are they?</div></div></div></blockquote><div><br></div><div>So far the responses from Atin/Nigel/Shyam have been helpful in shaping my
understanding of the problem and I documented an automated way to solve
this problem at <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1635826">https://bugzilla.redhat.com/show_bug.cgi?id=1635826</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> -- <br>
> Pranith<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-6576300964220583342gmail_signature"><div dir="ltr">Pranith<br></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Pranith<br></div></div></div></div>