<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 20, 2017 at 5:42 PM, Hari Gowtham <span dir="ltr"><<a href="mailto:hgowtham@redhat.com" target="_blank">hgowtham@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about the patches that are already posted against master and are<br>
yet to be reviewed?<br></blockquote><div><br></div><div>If its not merged in master, it is fine to merge to experimental.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is it fine to post them here and continue with the work further here<br>
or wait for these patches to get in master<br>
and then come to the experimental branch.<br></blockquote><div><br></div><div>If a patch lands in 'master' branch, I don't think there is any need to send it to 'experimental'. The idea of 'experimental' branch is to push features/changes which are not having enough confidence to make it to master branch, and get it tested in regression suite over time. <br><br></div><div>If its not merged, send it to experimental branch, get it merged, and if there is anything extra needs to be done, work on it, and once stable, send the aggregated patch to 'master' branch.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Asking this question because the patch is there for a very long time.<br>
<br></blockquote><div>Got it. And this is the very reason for getting 'experimental' branch done.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And it would be better to know what is the frequency in rebasing the<br>
master and the experimental branch.<br></blockquote><div><br></div><div>'master' branch rebase to experimental will be done once in 6 months, officially. I will try rebasing once a month, and see if there are no conflicts, I will force push the branch, but for now, thinking of 6 months frequency. There has been suggestion to keep it 3 months window (similar to that of release branch cut-off). Yet to finalize on that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And how has the permission to merge the patches in the experimental branch.<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div>Assuming it is 'who' and not 'how', Currently I (@amarts) have the permission to merge patches.<br><br></div><div>Regards,<br></div><div>Amar<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
On Tue, Jun 20, 2017 at 4:05 PM, Amar Tumballi <<a href="mailto:atumball@redhat.com">atumball@redhat.com</a>> wrote:<br>
> All,<br>
><br>
> As proposed earlier [1], the 'experimental' branch is now created and<br>
> active. Any submission to this branch is going to be accepted without too<br>
> much detailed review, and the focus will be to make sure overall design is<br>
> fine. I have put a deadline of a week max for reviewing and merging a patch<br>
> if there are no significant problems with the patch.<br>
><br>
> I welcome everyone to use this branch as an test bed to validate your ideas,<br>
> so your patch gets merged, and the nightly regressions would run on it for<br>
> some time. Also we are planning to give out RPMs from this branch every<br>
> week, so some features which gets completed in experimental can be tested by<br>
> wider user-base, and once validated, can land in master branch and<br>
> subsequently next release.<br>
><br>
> A note of caution: Getting a patch merged in experimental is in no way<br>
> guarantee to get your patch in any of the upstream glusterfs releases. The<br>
> author needs to submit the changes to 'master' branch to get the feature in<br>
> releases.<br>
><br>
> The branch already has some experimental features like:<br>
><br>
> metrics on 'fops' in every xlator layer, instead of only getting it with<br>
> io-stats.<br>
> latency related information is default.<br>
> few more metrics added in memory allocation checks.<br>
> All the above can be seen with sending SIGUSR2 signal to GlusterFS process.<br>
> (@ /tmp/glusterfs.* )<br>
><br>
><br>
> Regards,<br>
> Amar<br>
><br>
> [1] - <a href="http://lists.gluster.org/pipermail/maintainers/2017-May/002644.html" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>pipermail/maintainers/2017-<wbr>May/002644.html</a><br>
><br>
> --<br>
> Amar Tumballi (amarts)<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Gluster-devel mailing list<br>
> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Regards,<br>
Hari Gowtham.<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div>