<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 18, 2018 at 10:15 AM Pranith Kumar Karampuri &lt;<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 14, 2018 at 5:29 PM Shyam Ranganathan &lt;<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/09/2018 01:24 AM, Pranith Kumar Karampuri wrote:<br>
&gt; <br>
&gt; <br>
&gt; On Thu, Aug 9, 2018 at 1:25 AM Shyam Ranganathan &lt;<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br>
&gt; &lt;mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;     Maintainers,<br>
&gt; <br>
&gt;     The following thread talks about a merge during a merge lockdown, with<br>
&gt;     differing view points (this mail is not to discuss the view points).<br>
&gt; <br>
&gt;     The root of the problem is that we leave the current process to good<br>
&gt;     faith. If we have a simple rule that we will not merge anything during a<br>
&gt;     lock down period, this confusion and any future repetitions of the same<br>
&gt;     would not occur.<br>
&gt; <br>
&gt;     I propose that we follow the simpler rule, and would like to hear<br>
&gt;     thoughts around this.<br>
&gt; <br>
&gt;     This also means that in the future, we may not need to remove commit<br>
&gt;     access for other maintainers, as we do *not* follow a good faith policy,<br>
&gt;     and instead depend on being able to revert and announce on the threads<br>
&gt;     why we do so.<br>
&gt; <br>
&gt; <br>
&gt; I think it is a good opportunity to establish guidelines and process so<br>
&gt; that we don&#39;t end up in this state in future where one needs to lock<br>
&gt; down the branch to make it stable. From that p.o.v. discussion on this<br>
&gt; thread about establishing a process for lock down probably doesn&#39;t add<br>
&gt; much value. My personal opinion for this instance at least is that it is<br>
&gt; good that it was locked down. I tend to forget things and not having the<br>
&gt; access to commit helped follow the process automatically :-).<br>
<br>
The intention is that master and release branches are always maintained<br>
in good working order. This involves, tests and related checks passing<br>
*always*.<br>
<br>
When this situation is breached, correcting it immediately is better<br>
than letting it build up, as that would entail longer times and more<br>
people to fix things up.<br>
<br>
In an ideal world, if nightly runs fail, the next thing done would be to<br>
examine patches that were added between the 2 runs, and see if they are<br>
the cause for failure, and back them out.<br>
<br>
Hence calling to backout patches is something that would happen more<br>
regularly in the future if things are breaking.<br></blockquote><div><br></div><div>I&#39;m with you till here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Lock down may happen if 2 consecutive nightly builds fail, so as to<br>
rectify the situation ASAP, and then move onto other work.<br>
<br>
In short, what I wanted to say is that preventing lock downs in the<br>
future, is not a state we aspire for. </blockquote><div><br></div><div>What are the problems you foresee in aspiring for preventing lock downs for everyone?<br></div></div></div></blockquote><div><br></div><div>Bringing this up just in case you missed this mail.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lock downs may/will happen, it is<br>
done to get the branches stable quicker, than spend long times trying to<br>
find what caused the instability in the first place.<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;  <br>
&gt; <br>
&gt; <br>
&gt;     Please note, if there are extraneous situations (say reported security<br>
&gt;     vulnerabilities that need fixes ASAP) we may need to loosen up the<br>
&gt;     stringency, as that would take precedence over the lock down. These<br>
&gt;     exceptions though, can be called out and hence treated as such.<br>
&gt; <br>
&gt;     Thoughts?<br>
&gt; <br>
&gt; <br>
&gt; This is again my personal opinion. We don&#39;t need to merge patches in any<br>
&gt; branch unless we need to make an immediate release with that patch. For<br>
&gt; example if there is a security issue reported we *must* make a release<br>
&gt; with the fix immediately so it makes sense to merge it and do the release.<br>
<br>
Agree, keeps the rule simple during lock down and not open to<br>
interpretations.<br>
<br>
&gt;  <br>
&gt; <br>
&gt; <br>
&gt;     Shyam<br>
&gt; <br>
&gt;     PS: Added Yaniv to the CC as he reported the deviance<br>
&gt; <br>
&gt;     -------- Forwarded Message --------<br>
&gt;     Subject:        Re: [Gluster-devel] Release 5: Master branch health<br>
&gt;     report<br>
&gt;     (Week of 30th July)<br>
&gt;     Date:   Tue, 7 Aug 2018 23:22:09 +0300<br>
&gt;     From:   Yaniv Kaul &lt;<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a> &lt;mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>&gt;&gt;<br>
&gt;     To:     Shyam Ranganathan &lt;<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br>
&gt;     &lt;mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt;&gt;<br>
&gt;     CC:     GlusterFS Maintainers &lt;<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
&gt;     &lt;mailto:<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>&gt;&gt;, Gluster Devel<br>
&gt;     &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a> &lt;mailto:<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;&gt;,<br>
&gt;     Nigel Babu &lt;<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a> &lt;mailto:<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a>&gt;&gt;<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt;     On Tue, Aug 7, 2018, 10:46 PM Shyam Ranganathan &lt;<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br>
&gt;     &lt;mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a> &lt;mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt; <br>
&gt;         On 08/07/2018 02:58 PM, Yaniv Kaul wrote:<br>
&gt;         &gt;     The intention is to stabilize master and not add more patches<br>
&gt;         that my<br>
&gt;         &gt;     destabilize it.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt; <a href="https://review.gluster.org/#/c/20603/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/20603/</a> has been merged.<br>
&gt;         &gt; As far as I can see, it has nothing to do with stabilization and<br>
&gt;         should<br>
&gt;         &gt; be reverted.<br>
&gt; <br>
&gt;         Posted this on the gerrit review as well:<br>
&gt; <br>
&gt;         &lt;snip&gt;<br>
&gt;         4.1 does not have nightly tests, those run on master only.<br>
&gt; <br>
&gt; <br>
&gt;     That should change of course. We cannot strive for stability otherwise,<br>
&gt;     AFAIK. <br>
&gt; <br>
&gt; <br>
&gt;         Stability of master does not (will not), in the near term guarantee<br>
&gt;         stability of release branches, unless patches that impact code<br>
&gt;     already<br>
&gt;         on release branches, get fixes on master and are back ported.<br>
&gt; <br>
&gt;         Release branches get fixes back ported (as is normal), this fix<br>
&gt;     and its<br>
&gt;         merge should not impact current master stability in any way, and<br>
&gt;     neither<br>
&gt;         stability of 4.1 branch.<br>
&gt;         &lt;/snip&gt;<br>
&gt; <br>
&gt;         The current hold is on master, not on release branches. I agree that<br>
&gt;         merging further code changes on release branches (for example<br>
&gt;     geo-rep<br>
&gt;         issues that are backported (see [1]), as there are tests that fail<br>
&gt;         regularly on master), may further destabilize the release<br>
&gt;     branch. This<br>
&gt;         patch is not one of those.<br>
&gt; <br>
&gt; <br>
&gt;     Two issues I have with the merge:<br>
&gt;     1. It just makes comparing master branch to release branch harder. For<br>
&gt;     example, to understand if there&#39;s a test that fails on master but<br>
&gt;     succeeds on release branch, or vice versa. <br>
&gt;     2. It means we are not focused on stabilizing master branch.<br>
&gt;     Y.<br>
&gt; <br>
&gt; <br>
&gt;         Merging patches on release branches are allowed by release<br>
&gt;     owners only,<br>
&gt;         and usual practice is keeping the backlog low (merging weekly)<br>
&gt;     in these<br>
&gt;         cases as per the dashboard [1].<br>
&gt; <br>
&gt;         Allowing for the above 2 reasons this patch was found,<br>
&gt;         - Not on master<br>
&gt;         - Not stabilizing or destabilizing the release branch<br>
&gt;         and hence was merged.<br>
&gt; <br>
&gt;         If maintainers disagree I can revert the same.<br>
&gt; <br>
&gt;         Shyam<br>
&gt; <br>
&gt;         [1] Release 4.1 dashboard:<br>
&gt; <br>
&gt;     <a href="https://review.gluster.org/#/projects/glusterfs,dashboards/dashboard:4-1-dashboard" rel="noreferrer" target="_blank">https://review.gluster.org/#/projects/glusterfs,dashboards/dashboard:4-1-dashboard</a><br>
&gt; <br>
&gt;     _______________________________________________<br>
&gt;     maintainers mailing list<br>
&gt;     <a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a> &lt;mailto:<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>&gt;<br>
&gt;     <a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; -- <br>
&gt; Pranith<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_8341595512202744972gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div></div>