<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 24, 2012, at 1:02 PM, "Gearing, Chris" <<a href="mailto:chris.gearing@intel.com">chris.gearing@intel.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Nathan,<br><br>I'm not 100% sure what you are proposing here, your LAD presentation suggested a 'tune-up' of the current test framework rather than a complete re-write. Which of the two are we discussing?<br></blockquote>Both...<br><blockquote type="cite"><br>Which ever you are intending to undertake I think it is vital that before decisions are made on things such as languages a clear specification/definition of the activity is created and distributed. I am in fact working with Roman to bring such a document to the working group on the tune-up, making me somewhat confused about what is proposed here.<br><br>Going back to your LAD presentation for the tune-up your intention is to write some libraries to better address the requirements of the framework than is possible in bash, but those libraries would be called from the existing bash tests. This illustrates that the language used to develop the framework may not be the same language used for writing the tests, in fact I'm guessing that for both a tune-up and rewrite the requirements placed on the framework writer are different than those place on the test writer and so the languages required might well be different,</blockquote><blockquote type="cite">and in fact if this is a tune-up then surely the tests must continue to be written in bash even if the libraries are in something more applicable, we do not want a single framework with mixed languages (do we?)<br></blockquote><br>The ultimate goal is to produce higher-quality, more robust, well-controlled, and safer tests. To that end, I think the eventual language of the tests must change to something meeting the requirements I stated before:</div><div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>1. easy to use</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>2. strict structure</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>3. universally available/portable</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>4. widely maintained</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>5. widely understood</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>6. fully-featured filesystem interface: posix API</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>7. fast - replace e.g. createmany with embedded function</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>8. operate remote instances</div><div style="margin: 0px 0px 0px 30px; text-indent: -30px; font-size: 13px; font-family: Arial; color: rgb(108, 103, 1); "><span class="Apple-tab-span" style="white-space: pre; "> </span>9. inter-version compatibility</div><div>The requirements on the framework language are more relaxed, but for ease of development and developer sanity, I assume that the framework language should match the test language. So I'm using the test language as the requirements driver, and to gage community preference for that test language.</div><div><br></div><div>Based on the responses so far, it seems that there is a fairly clear preference for Python as a test language, and so I'll propose that Python should be used shorter-term to start replacing test-framework.</div><div><br></div><br><blockquote type="cite">So to return to my original question could you please provide some greater depth of insight as to what you are embarking upon, and then we can make more objective input as the language required.<br><br>On the complete-rewrite topic, I will post the slides I sent you before LAD to the Whamcloud wiki and then provide a link to this list so that people can share our thoughts. (Network access prevents me doing this immediately)<br><br>Regards<br><br>Chris<br>---------------------------------------------------------------------<br>Intel Corporation (UK) Limited<br>Registered No. 1134945 (England)<br>Registered Office: Pipers Way, Swindon SN3 1RJ<br>VAT No: 860 2173 47<br><br>This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.<br><br>_______________________________________________<br>Lustre-devel mailing list<br><a href="mailto:Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a><br>http://lists.lustre.org/mailman/listinfo/lustre-devel<br></blockquote></div><br></body></html>