<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Lets call the release 0.10 (oh-point-ten, per Ben) and save 1.0 for something further down the road, when we are in better shape to publicize.<div><br></div><div>Regarding features, lets spend all our effort on testing to make sure the release works on an important set of systems and configurations, which we should now list. Something like:</div><div><br></div><div>local</div><div>pbs (on PADS, Fusion, and a set of TG machines)</div><div>sge (on Ranger, IBIcluster, and a few PSD machines)</div><div>BG/P (intrepid, surveyor)</div><div>OSG over Condor-G</div><div>UCI systems?</div><div><br></div><div>If possible:</div><div><br></div><div>Sicortex</div><div>Amazon EC2</div><div>BioNimbus cloud</div><div>Magellan</div><div>FutureGrid</div><div><br></div><div>Im happy for the initial test to be a simple "catsn" script of N cat jobs w/ one file in and out.</div><div><br></div><div>Each of the systems above would need a few variations of coaster vs plain and a few data staging configs: local, provider-staging, gridftp.</div><div><br></div><div>If the doc set can be made release-specific and "testable" for 0.10 that would be great. If not, defer the per-release doc effort to 0.11.</div><div><br></div><div>The main features I'd like to see in 0.11 would be some of the error and logging improvements, and swiftconfig/swiftrun. Maybe support for Globus Online staging.</div><div><br></div><div>I dont want to think about those for 0.10 as I think "it works" is the most important feature for this next release. Lets define a test plan for the configs above and focus on how to automatically and repeatedly (ie nightly) validate the release on all these configs. That means a set of sites/tc/properties files and the integration of the tests, ideally, into the test harness.</div><div><br></div><div>- Mike</div><div><br><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;">so, my expectation for the release, as we've discussed somewhat on the list already, is to put out swift 1.0 on 12/20 which, as i see it, involves primarily editing of the documentation/web content more so than anything else since all new code (and documentation associated with the new code) going into trunk is expected to be in the 1.1. release--which hopefully we can have out in the next few months. i'm also assuming we're sticking with the plan to allow each release to have its own doc version along with the code. <br>
<br>let me know if anyone thinks there are other things that can/should go into the 12/20 release.<br><br>~sk<br><br><div class="gmail_quote">On Tue, Nov 23, 2010 at 2:10 PM, Michael Wilde <span dir="ltr"><<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
All,<br>
<br>
Sarah is going to take the lead in producing the next Swift release, and will propose a release definition and plan. We want to have the release done by Dec 20.<br>
<br>
- Mike<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
<a href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel" target="_blank">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a><br>
</blockquote></div><br>
</blockquote><br><span><br><br>-- <br><span name="x"></span>Michael Wilde<br>Computation Institute, University of Chicago<br>Mathematics and Computer Science Division<br>Argonne National Laboratory<br><span name="x"></span><br></span></div></div></body></html>