[PyOpenGL-Devel] Plans for a beta release sometime this week...
Brought to you by:
mcfletch
From: Mike C. F. <mcf...@ro...> - 2003-04-28 08:54:55
|
I'd like to get the point where we can do a beta release sometime in the next seven days or so. I will be spending a considerable portion of this week on PyOpenGL (and OpenGLContext). Here's what I like to see happen before the PyOpenGL beta (in case anyone would like to volunteer for items): * Python 2.3 compatibility o Currently the only problem appears to be Togl (I'm getting a segmentation fault him when trying to install, and there is an error during the build process where the API_version file is not present, I suspect a problem with mismatched Tk8.4.x builds). I don't know why it is expecting an API_version in that particular spot (I don't think togl is using API_version), will eventually track that down. o Test on Linux, preferably also Macintosh OSX * Python 1.5.2 compatibility o This hasn't been tested in... well, a long time. Anyone care ;) ? * RPMs for Red Hat o Set up the CVS repository's source to properly create the RPMs automatically with distutils o Requires defining the "provides" and "requires" specifications for the RPM system (not complex, but will probably take an hour or so) [MCF] * Build testing on Linux, Win32, OSX, (Sun, HP, Irix, AIX, *BSD) o Any pending patches/fixes should be called to my attention explicitly if they are not already integrated. o In essence, PyOpenGL should build properly from CVS without altering anything other than your platform .cfg file, preferably without requiring even that (where the platform's library/header locations are well-defined and predictable). o Inadequacies in the build instructions should be integrated into the installation/build documentation. + For instance, I have no idea what's required on OSX o I'll be posting a notice in a few days of a "build-candidate" in CVS (possible with a source tarball too) + Would be nice to get replies back for each built platform, with any notes on incompatabilities/problems. * Documentation re-generation [MCF] o For the beta release I would like to replace the current "manual" with just the reference converted with the modern doc-book XSLT. o The added-information sections (the "user manual") which are still relevant will likely be provided as a separate document. o Note that there is no current method available to me to create PNG-based equations, so the math-ml-based equations will almost certainly carry on for now. o The PDF engine requires the PNG-format equations, so similarly we likely won't have that * PyPi registration [MCF] o I've added the metadata required by PyPi, will register the project with the next release * Website review and update [MCF] o Basically do a review, nothing significant planned, just looking for bit-rot * Get un-attended build environment to our Win32 packaging volunteer o (build said environment ;) ) o If Rene has his copy of VC++ yet, this may be unnecessary (hope springs eternal :) ) * Linux/*nix niceties [volunteers?] o #! lines for all "script" .py files [MCF] o Make sure the files are all going to the right places o Make sure all files have proper permissions o Make sure various install types work (e.g. with su, without, however that works on Unix, make sure I haven't mistakenly included my own username or something silly like that in the RPMs (when I build them)) * Establish the set of distributable packages intended (may as well do that now, note that these are ones I would like to have *eventually* for the release if they are not "core", doesn't have to occur this week). Volunteers willing to act as packagers for the various platforms feel free to let me know who you are :) : o Core + Win32 Binary (w/ HTML Documentation) + Linux RPM + .zip and .tar.gz source distributions (w/ swig-generated wrappers) + HTML Documentation o Nice to have if possible + Mac bundle (not sure what these are actually called) + Red-Hat source RPM + Red-Hat docs RPM (or should that be part of source?) + .deb ? (is this something that the Debian maintainers do?) + .bsd ? (not sure there is a package format for the .bsd operating systems other than darwin, if so, would be nice to support that, will obviously require someone who has such a system ;) ). o For each binary format (I'm not sure we actually need to different versions for the different Tk versions, the theory, I believe, is that when built with 8.4 it should be compatible with a .3): + Python 2.3, {Numpy 23, Numpy 21}, {Tk83, Tk84}? + Python 2.2, {Numpy 23 (post-change), Numpy 21(pre-change)}, {Tk83, Tk84}? + Python 1.5.2, {Numpy 21}, {Tk83, Tk84}? -- realistically, I would like to drop this, as it seems hopelessly out of date Given the relatively slow pace of development for PyOpenGL (barring the introduction of a new C developer), I would imagine the beta period will be about two or three months to give people time to actually try this version with their applications, get error reports and patches in, and do the next release. Of course, if there is a reason, we can do another beta, but really, this is just a minor point release, primarily build and bug fixes (with the exception of the togl version shift), so I'm hoping we won't run run into anything significant. I'm expecting the beta to be basically stable, barring some significant mess-up on my part. Enjoy yourselves, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |