<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 28, 2017 at 12:57 AM, Vijay Bellur <span dir="ltr"><<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@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">Top posting here.<div><br></div><div>I would like to propose that all new features for 4.x have tests in glusto and that one successful run of those tests as a necessary condition for the release to happen. This effort would help us catch regressions that happen in multi node setups and also prevent accrual of further technical debt with respect to testing.</div><div><br></div><div>Thoughts?</div><div><br></div></div></blockquote><div><br></div><div>I understand the intent here, and would be very ideal for us as a project if we achieve it. </div><div><br></div><div>Two concerns I have to make it a necessary condition to release (or some more):</div><div><br></div><div>* Do we (as developers) aware of glusto framework and how to write tests at this time ? If not, this activity itself may take some time, and we are sure to miss the deadline.</div><div><br></div><div>* Is the glusto framework ready to get contributions?</div><div> - I may be naive in asking it, but how easy is it to add a new feature into it? specially something like GD2 (which is a core part of Gluster 4.0), or a feature like reflink which touches most of components, but is technically just 1 of the 50 fops we have?</div><div><br></div><div>Also we did ask this question or suggestion to have 'line coverage' report with you new component along with the feature to get the feature called 'supported', and I don't think any one signed-off on that.</div><div><br></div><div>Here is what I am thinking:</div><div><br></div><div>* Add as much as possible feature to 4.0, start with marking every one of them as 'experimental'.</div><div>* Move them out of 'experimental' bucket once the test cases are added.</div><div>* Aim to get most of these features out of 'experimental' by adding more test cases before release of 4.1/4.2 (which ever is going to be our LTM release).</div><div><br></div><div>This way, we get to keep the 4.0 release promise (both on features and timeline), and by our LTM, we can say which of it is 'recommended', and which is not.</div><div><br></div><div>My 2cents.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Thanks,</div><div>Vijay<div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 20, 2017 at 1:04 PM, Shyam Ranganathan <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
As this is a longish mail, there are a few asks below, that I request folks to focus and answer.<br>
<br>
4.0 is a STM release (Short Term Maintenance), further, 4.1 is also slated as a STM release (although the web pages read differently and will be corrected shortly). Finally 4.2 would be the first LTM (Long Term ...) in the 4.x release line for Gluster.<br>
<br>
* Schedule *<br>
The above also considers that 4.0 will release 2 months from 3.13, which puts 4.0 branching (also read as feature freeze deadline) around mid-December (4 weeks from now).<br>
<br>
4.0/1/2 release calendar hence looks as follows,<br>
<br>
- Release 4.0: (STM)<br>
- Feature freeze/branching: mid-December<br>
- Release date: Jan, 31st 2018<br>
- Release 4.1: (STM)<br>
- Feature freeze/branching: mid-March<br>
- Release date: Apr, 30th 2018<br>
- Release 4.2: (LTM, release 3.10 EOL'd)<br>
- Feature freeze/branching: mid-June<br>
- Release date: Jul, 31st 2018<br>
<br>
* Scope *<br>
<br>
The main focus in 4.0 is landing GlusterD2, and all efforts towards this take priority.<br>
<br>
Further big features in 4.0 are around GFProxy, protocol layer changes, monitoring and usability changes, FUSE catchup, +1 scaling.<br>
<br>
Also, some code cleanup/debt areas are in focus.<br>
<br>
Now, glusterfs/github [1] reads ~50 issues as being targets in 4.0, and among this about 2-4 are marked closed (or done).<br>
<br>
Ask1: Request each of you to go through the issue list and coordinate with a maintainer, to either mark an issues milestone correctly (i.e retain it in 4.0 or move it out) and also leave a comment on the issue about its readiness.<br>
<br>
Ask 2: If there are issues that you are working on and are not marked against the 4.0 milestone, please do the needful for the same.<br>
<br>
Ask 3: Please mail the devel list, on features that are making it to 4.0, so that the project board can be rightly populated with the issue.<br>
<br>
Ask 4: If the 4.0 branching date was extended by another 4 weeks, would that enable you to finish additional features that are already marked for 4.0? This helps us move the needle on branching to help land the right set of features.<br>
<br>
Thanks,<br>
Shyam<br>
______________________________<wbr>_________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/maintainers</a><br>
</blockquote></div><br></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/maintainers</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <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>