<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 7, 2018, 10:46 PM 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">On 08/07/2018 02:58 PM, Yaniv Kaul wrote:<br>
> The intention is to stabilize master and not add more patches that my<br>
> destabilize it.<br>
> <br>
> <br>
> <a href="https://review.gluster.org/#/c/20603/" rel="noreferrer 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 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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That should change of course. We cannot strive for stability otherwise, AFAIK. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Two issues I have with the merge:</div><div dir="auto">1. It just makes comparing master branch to release branch harder. For example, to understand if there's a test that fails on master but succeeds on release branch, or vice versa. </div><div dir="auto">2. It means we are not focused on stabilizing master branch.</div><div dir="auto">Y.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<a href="https://review.gluster.org/#/projects/glusterfs,dashboards/dashboard:4-1-dashboard" rel="noreferrer noreferrer" target="_blank">https://review.gluster.org/#/projects/glusterfs,dashboards/dashboard:4-1-dashboard</a><br>
</blockquote></div></div></div>