MINUTES, 2009.05.12
Present: Chris, Istvan, Jenny, Marek, Namshin
1. Open issues
All outstanding reviews completed except Titus's.
Issue 89. Chris: shelve does writeback=False by default, changing this
to True in Pygr would go against the general spirit - plus of course
cause massive memory usage. What would the benefits be? Namshin: after
posting, original issue turned out to be invalid - switching to True
doesn't improve performance; the problem is indexing & how it can be
redone. Chris: looks like an 0.9 issue (MS will tag it appropriately in
the tracker), that said this should be easy to improve - specifically
for Solexa, one can simply get rid of shelves and use numeric indexing.
2. Code review status
According to Chris, no ongoing work on the subject at present; some
issues still open in the tracker but have already been addressed and
will be closed soon (85, 86, 87). In the future we should of course
have all modules reviewed (with different people reviewing different
modules), basing on Titus's experience from his review. However, we are
not likely to get any other modules reviewed in time for the release of
0.8 - so let us officially suspend initiating any new reviewe until
after the release.
3. Adoption of the GitHub coding model
MS: Note that the "upstream" remote is not created or synchronised
automatically, one needs to set this up by hand. Appropriate
information will be posted on the Wiki.
Jenny: the learning curve for Git is quite steep.
4. Documentation
Chris will try to entirely updating documentation for 0.8 within a week.
However, this will probably not include having code from the docs work
as doctests. Moreover, what about code snippets which don't work on
their own? MS: Perhaps we should have (e.g. in appendices or at the end
of each chapter) larger scripts for different chapters of
documentation, containing such snippets. A proposal for this should be
circulated in pygr-dev - not until ongoing work on documentation
updates has been completed, though.
Another subject is going through Namshin's old recipes and updating
them for 0.8 (as well as possibly moving them to the Wiki in the
process). Could Kenny Daily, who has already done some work on in-Wiki
code examples, possibly handle this?
5. 0.7 vs. 0.8
Some changes to restore compatibility have already been made but there
were changes in the 0.8 branch (i.e. components moved around, as in the
case of annotation code) would require a (trivial) update to 0.7.
Finally, there may be some hitherto unnoticed problems - thorough
cross-version testing is needed!
The most obvious form of testing would be data exchange between the two
versions. This should match Pygr's list of types used in such exchanges:
sequence, annotation, alignment. XML-RPC communication (a special case
of data exchange) should be tested too. MS: at present a 0.8 client
cannot talk to a 0.7 server. To avoid such issues in the future we
should add some sort of versioning: either add a method returning the
server's version number to the client, or have each data-exchange class
contain its own version number. Chris: Either way this would be a new
feature so it won't be done for 0.8. To be done for now:
- add 0.7 pickle compatibility to 0.8;
- prepare a new release of 0.7 which would feature forward
data-exchange compatibility.
However, before we get this going we should make a decision regarding
cross-version testing: should this be standalone or incorporated into
our testing framework? Likely the latter. Either way, we need to:
- prepate appropriate old-version files (and possibly add them to
tests/data/);
- since it would obviously make little sense to bundle Pygr 0.7
with testing code, set up a 0.7 XML-RPC server somewhere (MBI?) and
allow the test to take advantage of a lists of such XML-RPC server.
Question: where should cross-version tests be run? Obvious answers -
either the buildbot or the new MBI testing machine.
Istvan: it wouldn't hurt to ask around whether we actually NEED
compatibility between 0.7 and 0.8.
6a. Release planning - packaging
Building a Windows installer: supported by distutils; Istvan has tried
it and it works fine, will of course have to build such installers
under Windows as long as Pygr doesn't work correctly when built with
MinGW.
Linux distro packages: RPM, possibly DEB as well). No strict
dependencies other than Python; where possible, may list python-mysql
and pysqlite as suggested/recommended packages. MS will try this
(after-meeting note: RPM packages supported by distutils but don't
build out of the box, the problem is known but not trivial to solve; no
support for DEB even in the latest standard-library versions of
distutils).
Python eggs: setuptools are needed to automatically build eggs. MS will
work on either getting our setup.py to support both setuptool and
distutils, or creating a separate setup script (there is nothing
magical about the name) based on setuptools.
Question: Do we need eggs? Istvan: we pretty much do if we want to
publish Pygr on PyPI (BTW. setuptools can automatically upload eggs
they build there). Chris: in that case, it makes sense for us to build
them.
Side note: Pygr tests aren't and shouldn't be in binary packages.
6b. Release planning - the upcoming testing version
Will be tagged and packaged after documentation updates have been
finished and all review-pending issues have been closed (will ask Titus
whether we can do this by around the time Chris finishes updating
docs). Also, we should check with Titus whether he feels this version
will be ready to be called a beta.
Windows packages: Istvan will build them for Python 2.5, running
Windows buildbots are needed to get other versions supported.
Feature creep :-) dir() functionality, as discussed on pygr-dev, has
recently been added to the Git master despite the feature freeze. Since
this is an extremely small feature, we've decided to ship it with 0.8
after all; however, care should be taken for all future commit to be
pushed into a dedicated "post-0.8" branch - that will make preparing
the release easier (won't have to selectively omit commits from the
master).
7. Error descriptions on the Web
In order to keep these synchronised with the code the relevant Web pages
should be kept in Git, as well as possibly distributed in Pygr packages.
Istvan: how about implementing this as a dedicated module with errors as
classes in it, with such classes capable of rendering themselves as
HTML or ReST? Chris/MS: OK. An appropriate issue will be added to the
tracker.
8. Bug reports on pygr-dev
We should have someone responsible for telling people posting their
problems to file an issue in the tracker if the problem is a bug; this
will most likely be MS. However, we need a clear definition of a bug!
Chris will post an initial version of such a list to pygr-dev, once it
has been completed it will then be posted on either the Wiki or
pygr-dev Web pages.
--
MS
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pygr-dev" group.
To post to this group, send email to pygr-dev@googlegroups.com
To unsubscribe from this group, send email to
pygr-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pygr-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
