<div dir="ltr"><div><div><div>All,<br><br></div>Here is another proposal, which I would like to start immediately to enable many features possible for Gluster 4.0 release.<br><br></div>We will create a 'new' branch called '<b>experimental</b>', where anyone can post a patch, for which only jenkins job which runs is 'smoke' (build + fops validation). <br><br><ul><li>This is where one can push any conceptual changes for review and get it merged quickly. </li><ul><li>To make sure we don't delay, after every 1 week if there are no merges, a patch would be merged. (If there are no -1).<br></li><li>Manually, it can be merged even before.</li></ul><li>Review comments on this branch is absolutely about concept and design, and no nitpicks. <br></li><li>even ./rfc.sh would be changed to allow (with a question) even in case of Errors.</li><li>All fundamental changes (like file type in GFID, DHT layout changes, etc) gets merged here first, and once baked can be taken as a single patch and get merged in master, which would make it to next release branch cut.</li><li>This branch would have life for 6 months, and after 6 months a new branch would be cut-off from master, so any features which can't be stabilized in 6 months, needs to be rebasing at least once in 6 months to new branch. This way, it would be much easier for everyone to experiment their ideas.</li><li>As this branch doesn't need a bugzilla ID to work, having github issues (for an RFE) would be important. This can fetch -1.</li><li>I am willing to maintain this branch to make sure it is in all its sanity, and keep track of patches which gets in.<br></li></ul><p>Let me know what each of you would think.<br></p></div><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 24, 2017 at 2:13 PM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>All,<br><br>Below is mainly a proposal, and I would like to hear people's thought on these.<br><br><ul><li>Over
the years, we have added many test cases to our regression test suite,
and currently the testing time stands at ~5hrs for 1 patch. But the
current way of '*.t' based regression can't be called as a 'complete'
test for the filesystem.</li></ul><ul><li>Correct me if I am wrong, but
even when we have to make a release, other than the same set of tests,
we don't have much to validate the build.</li><ul><li>Pranith / Aravinda, I heard there was some effort on these lines, and you guys prepared a list during 3.9 cycle, share them if relevant.<br></li></ul></ul><p>Now considering above points and taking the proposal of<a href="http://lists.gluster.org/pipermail/gluster-devel/2017-March/052245.html" target="_blank"> 'Good Build' from Nigel</a> [1], I am thinking of making below changes to how we look at testing and stability.</p><p><b>'What to test on nightly build':</b></p><ul><li>Build verification<br></li><li>Run all the regression as it runs now.</li><ul><li>Run CentOS regression<br></li><li>Run NetBSD regression<br></li></ul><li>Run coverity</li><li>Run gcov/lcov (for coverage)</li><li>Run more tests with currently optional options made as default (like brick-multiplexing etc).</li><li>Open
up the infra to community contribution, so anyone can write test cases
to make sure GlusterFS passes their usecases, everynight.</li><ul><li>Should be possible to run a python script, ruby script, or a bash script, need not be in a 'prove' like setup.</li></ul></ul><p><b>'master' branch:<br></b></p><ul><li>make the overall regression lightweight.</li><ul><li>Run what netbsd tests run now in CentOS regression (ie, basic and features in tests).</li><li>Don't
run netbsd builds, instead add a compilation test on centos 32bit
machine to keep reminding ourself how many warnings we get.</li></ul><li>Make sure 'master' branch is well tested in 'Nightly'.</li><li>Let
the approach of maintainers and over all project is to promote new
changes, instead of being very sceptical about new patches, ideas. </li><li>Provide
option to run the whole nightly build suit with a given patchset to
maintainers, so when in doubt, they can ask for the build to complete
before merging. Mostly applies to new feature or some changes which
change the way things behave fundamentally.</li></ul><p><b>'release-x.y' branch:</b></p><ul><li>During
the release-plan come out with target number of 'coverity' issues, and
line coverage % to meet. Also consider number of 'glusto-tests' to pass.<br></li><li>Agree
to branch out early (at least 45days, compared to current 30days), so
we can iron-out the issues caused by the making the 'master' branch
process lean.<br></li></ul><ul><li>Change the voting logic, add more tests now (Example: fall back to current regression suit).</li><li>On the first build, run agreed performance tests and compare the numbers with previous versions. </li><li>Run NetBSD regression now.</li><ul><li>Btw, noticed the latest NetBSD package is for 3.8.9 (done in Jan).</li><li>Work with Emmanuel <<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>> for better options here.</li></ul><li>Run nightly on the branch.</li><li>Block
the release till we meet the initially agreed metrics during the
release-plan. (like coverity/glusto-tests, line coverage etc).</li><ul><li>For 3.12 release itself we can fix the coverity completely, if all 30+ developers we have spend a day fixing these issues. Most of it is in general 1-2 line fixes.</li><li>Improving line-coverage in tests is an on-going effort IMO.</li><li>One of the suggestion was to 'Not' block release because of these, I am fine this as a best effort based approach.<br></li></ul><li><b>On the final release build:</b></li><ul><li>Run agreed performance tests and publish the numbers. Make sure it is not regressed.</li><li>Add install and upgrade tests to this mix (install should be covered when running above tests, but not upgrades)</li><li>Upgrade tests to test out all(?) options</li><li>Add, version compatibility tests</li><li>Add testing documented procedures into the mix, IOW, if we state "this
is how you setup(/recover from/address) XYZ" then have a test case for
that. This ensures documented procedures are right, or are improved over
time.</li></ul></ul><p><br></p><p>IMHO, We all proceeding on this is critical, as I saw that <a href="http://lists.gluster.org/pipermail/gluster-devel/2017-May/052844.html" target="_blank">(refer mail on 90days old patches)</a>[2], there were more than 600 patches which were old, and many of these are good patches which would make the project better.<br></p><p>Please
take time to review the points here and comment if any. Planning to
raise a ticket to Infra team by June 1st. Lets
move towards these changes by June 15th if there are not any serious
concerns.</p><br>[1] - <a href="http://lists.gluster.org/pipermail/gluster-devel/2017-March/052245.html" target="_blank">http://lists.gluster.org/piper<wbr>mail/gluster-devel/2017-March/<wbr>052245.html</a><br>[2] - <a href="http://lists.gluster.org/pipermail/gluster-devel/2017-May/052844.html" target="_blank">http://lists.gluster.org/piper<wbr>mail/gluster-devel/2017-May/<wbr>052844.html</a><br clear="all"><br><br></div>Regards,<br></div>Amar<span class="HOEnZb"><font color="#888888"><br><div><div>-- <br><div class="m_5862738021913843167gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div></font></span></div>
</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></div></div></div></div></div></div></div>