MINUTES, 2009.01.13 Present: Chris, Istvan, Jenny, Marek, Namshin
1. 0.8 status Close to at least tagging an alpha. Some most recent changes (i.e. issue 34) haven't had corresponding documentation updated yet. Request from Chris regarding practical testing of his recent Blast-related changes. Last major issue before alpha: short-term changes to Pygr.Data. Jenny expressed concern about excessive length of names after change - not a problem if namespaces are just a convention, not forced. Regarding timing, Jenny and Istvan suggest considering postponing this until 0.9 (long-term changes are scheduled for 1.0), Chris however would like to at least introduce new interfaces in 0.8 so that they do not change any more. Note that all changes will be backward-compatible. 2. Testing etc. General overview: - megatests - running, set-up documented, MS generalising scripts; - small tests - running but bench not documented; MS will ask Titus to document this; - building, compatibility - Titus's student was supposed to work on that, MS will ask T. for a progress report. Istvan asked about megatest requirements. Namshin: memory < 2 GB, disc space c.a. 200 GB, running time: short version about 1 hour on leelab2, long originally estimated at about 6 h but the number is uncertain (Namshin will test this). Namshin: Required resource reorganisation on UCLA megatest bench! MS will talk to Chris, summarise resources, get things ready. Chris requested detailed timing information to be added to megatests so that performance changes can be tracked. Namshin will implement them. 2a. Test framework rewrite by Istvan Almost everything in testing framework transferred to new structure. To do: blast code, megatests; Istvan needs a few more days to finish this. After that, changes can be reviewed and possibly incorporated into master. Note from Chris: we should have Titus around for that. Istvan: In addition to addressing Windows incompatibilities the rewrite makes it easier for developers to add their own test (framework more simple), also high modularity (tests can now be run one by one, i.e. directly from the editor). Chris: what tests can be skipped and not treated as errors? Istvan: at present only SQL tests are skippable (this includes some non-Pygr errors such as permission issues). 2b. Pygr message clean-up Proposal from Istvan: replace all prints with calls to the logger module! See pygrlogger.py (sp?) in his repository on github for usage example. Istvan will open an issue on the tracker regarding this as well as work on migrating most of the current code. Note: once the module has been imported and formatters for different log levels have been defined, actual message-related changes can be made gradually. Request: all devs please get in habit of using logger instead of print! Question of verbosity: presently long messages by default which can be suppressed. Istvan: can cause problems because in some cases it's all-or-nothing. Suggestion: use short error messages with links to long explanations. Will add an issue to tracker. Jenny will propagate those changes to PyEnsembl. 2c. Misc. testing Issue 33: can be marked closed but needs testing. Chris has written an order-by test for GraphView but not for this. Jenny will follow up. 3. Code Review First review will happen on SeqDB. Need Titus for that! Then subdivide modules between people. MS: how hard will it be to test all modules, esp. in case of devs not that familiar with them? Results from Titus may or may not shed light on that. Will likely tag alpha before the review, final version will wait for finish. Schedule needed! Volunteers requested for modules they would like to review. MS: follow up with Titus. 4. Documentation Chris will upgrade most out-of-code documentation. Issue: things like Pygr Cookbook need to be checked AND moved to new location - most likely committed to the Git repository as doctests, then generate HTML from those doctests during testing runs. Chris: how many Cookbook recipes are too large to become doctests? Namshin thinks only about 5 are large. Question of code examples posted on the Wiki. These should probably end up as doctests too, with Wiki devoted to general issues and non-code notes. Lack of direct Git support in Google Code a hindrance, hopefully this will be addressed by Google relatively soon. Documentation/testing task force: Istvan, MS, Namshin, Titus 5. Getting people involved - use tracker a lot, including posting progress reports on issues - general call to pygr-dev: if you see an issue you feel like being able to fix, go ahead! - pull in more students! - after 0.8 release: Advertise Pygr to sites with Python recipes, git.or.cz list of projects, freshmeat, ... Long-term: write some articles and paper(s) about this. Concentrate on others can't do. Istvan: data from new high-throughput sequencers presents an opportunity for Pygr, we should think about detailed work-flow documentation aimed at such audience. 6. Next meeting Tuesdays 17:00 Pacific fine for everyone. Tentative date of next meeting: 2009.01.27. -- MS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
