0.7 Release Plan

[leec]

This release plan summarizes discussion of C. Lee and N. Kim, Apr. 5 2007.

Current status: the pygr 0.7alpha is functionally complete.  The code is in production use for Namshin's primer design online server, and appears to be working fine.  Documentation of all new features is complete (http://bioinfo.mbi.ucla.edu/~leec/pygr/).  The final steps for release include generating "cookbook recipes" showing beginning and intermediate users how to do typical tasks that people want to use pygr for, and improvements to QA and multi-platform support.

1. Beginning user focus

• Create a list of most common questions / tasks that users want to do, with answers including example code that will immediately work, using pygr.Data to access biodb2 resources.
• Will require some simple pygr.Data default PYGRDATAPATH  to access biodb2 resource database

2. Intermediate User focus

• Create a list of most common questions / tasks that users want to do, with answers including example code that will immediately work, using pygr.Data to access biodb2 resources, or downloading / installing data resources for large-scale analysis.
• Basic recipes for downloading, building and saving large datasets in local pygr.Data

The existing dataset on biodb2 should be adequate for this release.

3. QA

• Code review
• new regression tests for NLMSA, Seqdb, XMLRPC services
• Build and test on multiple UNIX platforms (linux, Mac OS X, sun) and if possible Windows.  Namshin has already successfully made a Windows build and Windows installer, but comprehensive testing of our regression suites is needed.
  

Timetable
Our initial estimate is 2-4 weeks for phases 1 and 2, and 2-3 weeks for phase 3.  Thus our target date for release is approximately the end of May. 

Initial Steps

• Namshin will make a draft list of questions for Beginning users, and I will add to it
• We will write code examples using pygr.Data that answer all of these questions.
• These examples will be presented as a "cookbook" of "recipes" (similar to the  ActiveState Python Cookbook), stored in Plone.  We'll use keywords and "topics" to create logical groupings of recipes for users to search or browse.

[leec]

Given the v.0.7 (pygr.Data) release's focus on working with large datasets, testing has been a bit of a puzzle.  We have always included an automated test suite with the source code package.  However, we obviously can't include big datasets in the package, so how can we code our tests so that they will automatically run only those tests that are possible in the user's local environment and resources?  It's taken a little while to sort out these issues, but it's done.  Here's a summary of our testing approach:

• We are using nose as the automated testing framework.
• We moved our existing unit tests to be run by nose.
• We are adding our extensive tutorial examples as a wide-ranging set of functional tests.  The main goal is for the complete set of tests to be sensitive to failures in just about any area of pygr functionality.  So, for example, checking that the calculated percent identity for each result in a multigenome alignment query matches the stored correct result is very sensitive to many functions working right (correct construction of the alignment; correct query results; correct sequence interval retrieval; etc.)
• Major data dependencies for individual tests will be managed with pygr.Data.  That is, each test setup() will simply try to obtain the data it needs by requesting named pygr.Data resources.  If required data are missing, the test will be skipped.  In my lab, we will keep a nightly test platform where ALL tests must pass (no skipping!).
• Tests that take a long time or a lot of resources (e.g. 28 vertebrate genome alignment NLMSA build) will have the suffix "_megatest" (instead of the default suffix "_test"), and thus will be omitted by a normal nosetests run.  We will include all megatests on our nightly test platform.
• The current goal is to complete the new generation of automated tests (functional tests), and fix whatever bugs we find, by the end of July.  The goal is to have good (but not great) coverage via these functional tests.
• These tests are the last step for the 0.7 release.  The functionality, documentation and tutorials are all done and posted on the web.  So our goal is to release 0.7 in early August.