<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 9, 2018 at 1:25 AM Shyam Ranganathan <<a href="mailto:srangana@redhat.com">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">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></blockquote><div><br></div><div>I think it is a good opportunity to establish guidelines and process so that we don't end up in this state in future where one needs to lock down the branch to make it stable. From that p.o.v. discussion on this thread about establishing a process for lock down probably doesn't add much value. My personal opinion for this instance at least is that it is good that it was locked down. I tend to forget things and not having the access to commit helped follow the process automatically :-).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>This is again my personal opinion. We don't need to merge patches in any branch unless we need to make an immediate release with that patch. For example if there is a security issue reported we *must* make a release with the fix immediately so it makes sense to merge it and do the release.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 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>><br>
To: Shyam Ranganathan <<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>>, Gluster Devel<br>
<<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>>, Nigel Babu <<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>>> 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 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 and its<br>
merge should not impact current master stability in any way, and 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 geo-rep<br>
issues that are backported (see [1]), as there are tests that fail<br>
regularly on master), may further destabilize the release 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 owners only,<br>
and usual practice is keeping the backlog low (merging weekly) 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><br>
<a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
</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>