<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 18, 2018 at 10:15 AM Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>> 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 <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>> 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>
> <br>
> <br>
> On Thu, Aug 9, 2018 at 1:25 AM 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>
> Maintainers,<br>
> <br>
> The following thread talks about a merge during a merge lockdown, with<br>
> differing view points (this mail is not to discuss the view points).<br>
> <br>
> The root of the problem is that we leave the current process to good<br>
> faith. If we have a simple rule that we will not merge anything during a<br>
> lock down period, this confusion and any future repetitions of the same<br>
> would not occur.<br>
> <br>
> I propose that we follow the simpler rule, and would like to hear<br>
> thoughts around this.<br>
> <br>
> This also means that in the future, we may not need to remove commit<br>
> access for other maintainers, as we do *not* follow a good faith policy,<br>
> and instead depend on being able to revert and announce on the threads<br>
> why we do so.<br>
> <br>
> <br>
> I think it is a good opportunity to establish guidelines and process so<br>
> that we don't end up in this state in future where one needs to lock<br>
> down the branch to make it stable. From that p.o.v. discussion on this<br>
> thread about establishing a process for lock down probably doesn't add<br>
> much value. My personal opinion for this instance at least is that it is<br>
> good that it was locked down. I tend to forget things and not having the<br>
> 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'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>
> <br>
> <br>
> <br>
> Please note, if there are extraneous situations (say reported security<br>
> vulnerabilities that need fixes ASAP) we may need to loosen up the<br>
> stringency, as that would take precedence over the lock down. These<br>
> exceptions though, can be called out and hence treated as such.<br>
> <br>
> Thoughts?<br>
> <br>
> <br>
> This is again my personal opinion. We don't need to merge patches in any<br>
> branch unless we need to make an immediate release with that patch. For<br>
> example if there is a security issue reported we *must* make a release<br>
> 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>
> <br>
> <br>
> <br>
> Shyam<br>
> <br>
> PS: Added Yaniv to the CC as he reported the deviance<br>
> <br>
> -------- Forwarded Message --------<br>
> Subject: Re: [Gluster-devel] Release 5: Master branch health<br>
> report<br>
> (Week of 30th July)<br>
> Date: Tue, 7 Aug 2018 23:22:09 +0300<br>
> From: Yaniv Kaul <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a> <mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>>><br>
> To: 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>>><br>
> CC: GlusterFS Maintainers <<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
> <mailto:<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>>>, Gluster Devel<br>
> <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a> <mailto:<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>>>,<br>
> Nigel Babu <<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a> <mailto:<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a>>><br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Tue, Aug 7, 2018, 10:46 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>><br>
> <mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a> <mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>>>> wrote:<br>
> <br>
> On 08/07/2018 02:58 PM, Yaniv Kaul wrote:<br>
> > The intention is to stabilize master and not add more patches<br>
> that my<br>
> > destabilize it.<br>
> ><br>
> ><br>
> > <a href="https://review.gluster.org/#/c/20603/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/20603/</a> has been merged.<br>
> > As far as I can see, it has nothing to do with stabilization and<br>
> should<br>
> > be reverted.<br>
> <br>
> Posted this on the gerrit review as well:<br>
> <br>
> <snip><br>
> 4.1 does not have nightly tests, those run on master only.<br>
> <br>
> <br>
> That should change of course. We cannot strive for stability otherwise,<br>
> AFAIK. <br>
> <br>
> <br>
> Stability of master does not (will not), in the near term guarantee<br>
> stability of release branches, unless patches that impact code<br>
> already<br>
> on release branches, get fixes on master and are back ported.<br>
> <br>
> Release branches get fixes back ported (as is normal), this fix<br>
> and its<br>
> merge should not impact current master stability in any way, and<br>
> neither<br>
> stability of 4.1 branch.<br>
> </snip><br>
> <br>
> The current hold is on master, not on release branches. I agree that<br>
> merging further code changes on release branches (for example<br>
> geo-rep<br>
> issues that are backported (see [1]), as there are tests that fail<br>
> regularly on master), may further destabilize the release<br>
> branch. This<br>
> patch is not one of those.<br>
> <br>
> <br>
> Two issues I have with the merge:<br>
> 1. It just makes comparing master branch to release branch harder. For<br>
> example, to understand if there's a test that fails on master but<br>
> succeeds on release branch, or vice versa. <br>
> 2. It means we are not focused on stabilizing master branch.<br>
> Y.<br>
> <br>
> <br>
> Merging patches on release branches are allowed by release<br>
> owners only,<br>
> and usual practice is keeping the backlog low (merging weekly)<br>
> in these<br>
> cases as per the dashboard [1].<br>
> <br>
> Allowing for the above 2 reasons this patch was found,<br>
> - Not on master<br>
> - Not stabilizing or destabilizing the release branch<br>
> and hence was merged.<br>
> <br>
> If maintainers disagree I can revert the same.<br>
> <br>
> Shyam<br>
> <br>
> [1] Release 4.1 dashboard:<br>
> <br>
> <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>
> <br>
> _______________________________________________<br>
> maintainers mailing list<br>
> <a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a> <mailto:<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>><br>
> <a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
> <br>
> <br>
> <br>
> -- <br>
> 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>