<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 12, 2012, at 12:48 PM, Bruce Korb wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Nathan,<br></div></blockquote><div><br></div><div></div><blockquote type="cite"><div></div></blockquote><blockquote type="cite"><div>On 2012-07-12, at 20:37, Nathan Rutman <<a href="mailto:nathan_rutman@xyratex.com">nathan_rutman@xyratex.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><div><div>On Jul 12, 2012, at 7:30 AM, John Carrier wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: 'Courier New'; font-size: 13px; ">A more strategic solution is to do more testing of a feature release<br>candidate _before_ it is released.  Even if a Community member has no<br>interest in using a feature release in production, early testing with<br>pre-release versions of feature releases will help identify<br>instabilities created by the new feature with their workloads and<br>hardware before the release is official. </span></span></blockquote></div><br><div><br></div><div>Taking a few threads that have discussed recently, regarding the stability of certain releases vs others, what maintenance branches are, what testing was done, and "which branch should I use":</div><div>These questions, I think, should not need to be asked.  Which version of MacOS should I use?  The latest one, period.  Why can't Lustre do the same thing?  The answer I think lies in testing, which becomes a chicken and egg problem.   I'm only going to use a "stable" release, which is the release which was tested <i>with my applications</i>.  I know acceptance-small was run, and passed, on Master, otherwise it wouldn't be released.  Hopefully it even ran on a big system like Hyperion.  (Do we learn anything more about running acc-sm on other big systems?  Probably not much.)  But it certainly wasn't tested with my application, because I didn't test it.  Because it wasn't released yet.  Chicken and egg.  Only after enough others make the leap am I willing to.</div><div>So, it seems, we need to test pre-release versions of Lustre, aka Master, <i>with my applications</i>.  To that end, how willing are people to set aside a day, say once every two months, to be "filesystem beta day".  Scientists, run your codes, users, do your normal work, but bear in mind there may be filesystem instabilities on that day.  Make sure your data is backed up.  Make sure it's not in the middle of a critical week-long run.  Accept that you might have to re-run it tomorrow in the worst case.  Report any problems you have.</div><div>What you get out of it is a much more stable Master, and an end to the question of "which version should I run".  When released, you have confidence that you can move up, get the great new features and performance, and it runs your applications.  More people are on the same release, so it sees even more testing. The maintenance branch is always the latest branch, you can pull in point releases with more bug fixes with ease. No more rolling your own Lustre with Frankenstein sets of patches.  Latest and greatest and most stable.</div><div><br></div><div>Pipe dream?</div></div></blockquote></blockquote><br>On Jul 12, 2012, at 12:48 PM, Bruce Korb wrote:<br><blockquote type="cite"><div><br>_I_ think so.  You might get a few customers to say, "yes" but<br>never be able to find the appropriate round tuit.  A more fruitful<br>approach might be to solicit customer acceptance tests.  Presumably,<br>they've written them to hit the wrinkles that they tend to stub<br>their toes on.  And there may be exceptions, too.  (e.g. Cray might<br>well actually do some pre-testing -- they, too, have paying customers.)<br><br></div></blockquote></div><div><br></div>I have no aversion to customers writing and supplying their own acceptance tests, but I think that approach doesn't work for many of the cases:<div>- acceptance tests may not exist; acceptance may simply be testing with large production codes</div><div>- tests that run in a particular environment need to be significantly generalized</div><div>- tests may not be sharable for various legal reasons</div><div><br></div><div>This also doesn't have to be an all-or-nothing proposition -- interested parties will be able to use the latest features, and will help contribute to the stability of Master, and will help reduce the "spread" of deployed systems, in a positive feedback loop.</div><div><br></div><div>Yes, absolutely, this is effort on the part of Lustre users.  But it can be balanced by the savings of efforts in roll-your-own, and risk reduction.</div><div><br></div><div> </div></body></html>