Tavis Rudd wrote: > On Tuesday 02 April 2002 06:55, you wrote: > > Now that 0.7 is out, I think it's high time that we moved Webware > > in the direction of a 1.0 release. What things still need to be > > done? > > In order of priority: > > - completely automated test suite, that is easy to add new tests to > > - distutils support, remove ability to run straight from the install > dir, and remove need to run makeAppWorkingDir.
What takes the place of MakeAppWorkDir if we switch to distutils? (I know nothing about distutils.) We still have configuration files, cache dirs, cgi scripts, etc. that MakeAppWorkDir sets up for us, and that will presumably continue to be useful. > - a semi-automated release cutting script, that 'cvs up's, updates > version numbers, runs the automated test suite, presents the release > manager with a summary of all the @@ comments in the source tree and > a form to add the release notes, builds the docs and the release > tarball, does a dummy install of the tarball and runs the test suite > from it, commits the changes to the cvs and adds a new tag, uploads > the tarball file to upload.sf.net, runs an automated https session to > log the release manager into sf and post the new release, sends a > release email to webware-discuss/webware-announce/comp.lang.python, > and updates the vaults of parnassus. A goal could be for it should > take no more than an hour to cut a beta release. That would be very nice. I'm a little worried about testing this release-cutting script though -- I don't want it to go haywire and start sending broken announcement emails, updating VoP with bad data, etc. but how else do you test the script other than actually doing a release? Also, the pages for updating SourceForge and VoP may change over time, breaking the release script. Perhaps the "risky" steps at the end of the release should remain manual. > > - documentation (formated in either xml-docbook or LaTeX) I don't know the pros and cons vs. our current use of simple HTML with CSS. I definitely don't want to see it get any harder to maintain the docs than it is now. This probably isn't going to happen unless someone volunteers to do the conversion and maintain the docs. And even then, I'm not sure Chuck will buy into it -- I know the last time this was discussed he expressed a preference for the current format :-) > - better handling of config settings: > - refactored to use the wrapper pattern, in which each class is > given its settings from the 'Launcher' wrapper instead of having to > go and get them. > - better config file syntax (pure python or the one used in > WebwareExpRefactoring) I don't see the necessity for these changes -- I get by just fine with the current config files. Perhaps it could be a bit more flexible, but in practise I don't see how I would really benefit from that flexibility. > - ability to provide local subclasses of core classes such as > Application That would be great, but not IMHO necessary for 1.0. > - a better logging framework: > - separation of error reporting from error logging > - based on either Sacha's LoggingKit or PEP 282 > (http://python.sourceforge.net/peps/pep-0282.html) > - ability for multiple Webkit process to write to the same log > (syslog, NT event log, or something similar but Webware specific) Also not necessary for 1.0 IMHO. Python may grow its own logging module soon -- I think there's a PEP and a reference implementation already. So I'd rather wait and see if that makes it in. > > The only item I feel is essential is to write reasonably complete > > automated tests. I'd like to be able to sync to the tip of CVS and > > run a single command to fully test every Webware component. > > I agree, this absolutely essential. See the automated testing > framework in the experimental refactoring of Webware I've been > working on > (http://webware.colorstudy.net/twiki/bin/view/Webware/WebwareExpRefactoring) . > The most difficult and labour intensive part of this is being able to > auto-load, run, and shutdown a WebKit process. This requires a > builtin http server and a simple mechanism for controlling the config > settings. I refactored the configuration mechanism and made it so > all settings can be fed into the process via a pickled dictionary. > For testing, this is way simpler than having to write each config > file separately. It doesn't require a builtin http server if we just require Apache to be used for testing. We want to test the Apache adapters after all... And writing out config files in the current form is easy. You can suck in an existing config file using eval(), modify it, and spit it out with repr() or pprint.pformat(). - Geoff _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
