[Zope-Checkins] CVS: Zope/doc - TODO.txt:1.1.2.6
Jim Fulton
jim@zope.com
Fri, 28 Feb 2003 14:43:26 -0500
Update of /cvs-repository/Zope/doc
In directory cvs.zope.org:/tmp/cvs-serv5127
Modified Files:
Tag: new-install-branch
TODO.txt
Log Message:
Chris, Fred and Jim brought the to do list up to date in preparation
for merging into the trunk.
=== Zope/doc/TODO.txt 1.1.2.5 => 1.1.2.6 ===
--- Zope/doc/TODO.txt:1.1.2.5 Thu Feb 27 18:20:44 2003
+++ Zope/doc/TODO.txt Fri Feb 28 14:43:19 2003
@@ -13,92 +13,13 @@
path)
-------------------------
- TODO FOR MERGE
+ TODO BEFORE MERGE
-------------------------
-Critical review of config file schema
+Modify zopectl to read configuration file from the zope config file
- A config file is a contract with the user. We want to get the Zope
- config file as right as possible the first time, as it will be very
- hard to change later. One of the tricks to doing this is to make
- sure that as few keys and sections as possible in the config are
- "required", so that if we *do* need to change the schema for the
- config later it is likely not to impact a majority of users (as most
- of them will be sticking with the defaults). We provide sane
- defaults for most things via default= in ZConfig schema and
- procedural code in ZConfig "handlers". We would optimally like the
- default Zope config file to be able to be "empty" and still have
- Zope work. This is currently not the case (instancehome is a
- required key).
-
-Replace ZCtlLib/zopectl with zdctl variant
-
- Replace the current ZCtlLib/zopectl stuff with a variant of Guido's
- zdctl/runsrvr system, which we might call "zopectl".
-
- Issues:
-
- - I dont think we need a config file for zopectl. We should give
- it sensible hardcoded defaults instead, and it should probably
- be capable of reading the Zope config file to find out the
- things it needs to know (logfile placement comes to mind).
-
- XXX logfile placement and the command to execute really seem to
- be the only things that are otherwise computable; it that really
- worth creating a less-general script? The right defaults can be
- provided by the mkzopeinstance script.
-
- - zdctl/zdrun doesn't do Windows. It would be nice to have a
- zopectl on Windows but not strictly necessary. If there is no
- zopectl on Windows, we will need to spell this out in the docs.
- We will also need the ntservice.py module to issue different
- commands to start and stop the service.
-
- Status: A simple version has been implemented, but it does not yet
- address the first issue above (nor is it clear that no config file
- should be needed).
-
-Deal with command-line-specified overrides to configuration values
-
- It is currently not possible to override config file-specifed values
- by using arguments to zopectl or runzope. This will be required in
- reality. There is a bunch of code that anticipates this possibility
- in zope.py and Zope.Startup.ZctlLib.py (anything that mentions
- "overrides" or "getSchemaKeys" is likely aiming to deal with this),
- but none of it actually works.
-
- XXX This was done somewhat via a cmdline.py module in Zope/Startup
- but needs to be replaced with zdoptions.
-
- Status: ZConfig + zdoptions now provides a -X option to allow
- setting a ZConfig value from the command line, but this is still
- limited. The "legacy" command line options provided by Zope 2.6
- have not yet been implemented.
-
-Write some unit tests
-
- Write unit tests for Zope.Startup packages.
-
-Make sure ZConfig datatype conversion and handler errors are caught
-the right way by runzope
-
- lib/python/zope.py is the responsible for causing the zconfig
- configuration file to be parsed, and needs to deal with errors in a
- sane way. This is tricky because it now houses the top-level
- exception handler which needs to do sane things to distinguish
- between configuration errors, true system exit, and unknown errors.
-
-Config file needs better inline docs
-
- The Zope ZConfig config file has some inline docs. They need to be
- completed. To centralize this data, the docs might be done in the
- schema itself. A schema introspector which generates the default
- config file could be created.
-
-Sanity check help and usage output of command-line programs
-
- Make sure runzope and zopectl have sane help output
- (make sure it matches the capabilities of the system).
+ This, in part is so it can know the path to the log filr without
+ being told.
Test 'effective user' support
@@ -108,42 +29,13 @@
disk (maybe via unit tests) before Zope has had a chance to switch
effective users.
-Performing the merge
-
- All changed files are located on the new-install-branch; this
- includes additions and removals as well. Each changed portion of
- the tree (which may be whole subtrees or individual files) needs to
- be merged into the trunk separately, and then testing and commit for
- the whole should be performed as a unit.
-
-Review impact of missing Data.fs.in
+Reexport example import file to avoid stale Pythonscript byte codes
- The branch install process doesn't copy the "Data.fs.in" file to an
- instancehome/var directory. This file is the "initial" filestorage
- for Zope that gets copied to "Data.fs" during installation in every
- prior branch of Zope. This file is evil and must die at some point,
- and most of the necessary code to set things up properly in the face
- of an empty Data.fs already exists in OFS.Application.initialize.
- Things seem to work fine without Data.fs.in but we should just give
- it a bit of review to see what gets left out, if anything.
+Update INSTALL.txt
- When we find that Data.fs.in isn't necessary, we need to remove it
- from the HEAD.
+Remove RPM support
- XXX What is actually needed to verify that it isn't needed?
-
- AAA THe best way to do this is to write a unit test which verifies
- that the default objects installed into a "new" ZODB when Zope
- starts are present and working, and their content either matches
- the content of what would have come from Data.fs.in or is "close
- enough". The code that installs these default objects exists in
- the initialize function within lib/python/OFS/Application.
-
-Figure out why Zope complains about stale PythonScripts at startup
-
- After Zope is installed via the default installation routine, it
- complains about stale PythonScripts in some cases. I haven't
- investigated this, but it needs to be fixed.
+Remove the top-level pcgi directory
Notifying owners of automated testers
@@ -159,46 +51,40 @@
Packages/TestScripts/newinstallbranch.xml. No further action is
needed at this time.
-Review the Zope Book 2.6 Edition chapters and come up with revisions
-or at least create a Zope Trunk Install HowTo
+Notify the community
- The 2.6 edition Zope Book at
- http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition has
- three chapters which detail installation (installing and starting
- zope), maintenance (maintaining zope) and ZEO (scalability and ZEO).
- These chapters should be reviewed for inaccuracies with respect to
- the forthcoming trunk changes and changes should be made "offline"
- to allow a Zope Book 2.7 edition.
+ This note will point at INSTALL.txt.
+
+ Ask them for input on the need for backward compatible command-line
+ tools (e.g. start/stop/z2.py). Do we need to support old environment
+ variables?
+
+Performing the merge
+
+ All changed files are located on the new-install-branch; this
+ includes additions and removals as well. Each changed portion of
+ the tree (which may be whole subtrees or individual files) needs to
+ be merged into the trunk separately, and then testing and commit for
+ the whole should be performed as a unit.
- At least create a HowTo which summarizes the differences between
- installing 2.6 and installing the trunk.
--------------------------------
BEFORE RELEASE OF ZOPE 2.7A
--------------------------------
-Default logging destinations
-
- If logging parameters are unspecified in the configuration, the
- default is to log zLOG messages to CLIENT_HOME/event.log and to log
- access messages to CLIENT_HOME/access.log. This differs from older
- branches inasmuch as log messages in default mode (aside from
- startup messages) will no longer be written to stdout.
- STUPID_LOG_FILE and friends no longer have any effect.
+Config file needs better inline docs
- This is also why logtail is a desirable option (to give back this
- useful feature).
+ The Zope ZConfig config file has some inline docs. They need to be
+ completed.
- This change needs to be communicated in docs and to developers in
- some way.
+Make as many things defaultable as feasible
+ Maybe we can allow a config file in which everything is commented
+ out. We'll see.
-"configure" shell scripts need peer review
+Write some more unit tests
- I'd like someone to review the "configure" and "configure.bat"
- scripts in the top-level directory and suggest/make changes. These
- scripts help find a suitable Python interpreter and create a
- Makefile on UNIX and Windows, respectively.
+ Write unit tests for Zope.Startup packages.
Update Zope distribution creation machinery
@@ -244,44 +130,52 @@
The "win32-eventlog" log handler (which is creatable via the config
file) needs to be tested.
-RPM install should recompile .pycs
+Server construction errors need to be better
- The RPM spec file (inst/Zope.spec.in) should delete and recompile
- .pycs/.pyos during an RPM install to make sure tracebacks contain
- real Zope filenames instead of filenames relative to the build
- directory. Alternately the RPM install should not contain .pycs or
- .pyos.
+ When a server is constructed, it attempts to bind to a port. If the
+ port cannot be bound, an error is raised. The error currently doesn't
+ include the port number, and should.
- XXX Not clear why this is actually needed; importing a module causes
- the __file__ to be updated with the right filename. A nice touch,
- but not required.
+Review impact of missing Data.fs.in
- AAA Is this a new Python feature or has it always been this way?
- Tracebacks used to show the location of the .pyc where it had been
- compiled, not where it actually lived.
+ The branch install process doesn't copy the "Data.fs.in" file to an
+ instancehome/var directory. This file is the "initial" filestorage
+ for Zope that gets copied to "Data.fs" during installation in every
+ prior branch of Zope. This file is evil and must die at some point,
+ and most of the necessary code to set things up properly in the face
+ of an empty Data.fs already exists in OFS.Application.initialize.
+ Things seem to work fine without Data.fs.in but we should just give
+ it a bit of review to see what gets left out, if anything.
-RPM install versioning scheme needs to be documented
+ When we find that Data.fs.in isn't necessary, we need to remove it
+ from the HEAD.
- The RPM builder has a versioning scheme via the generated Makefile
- in order to allow for the install of multiple simultaneous versions
- of Zope on a single system. This versioning scheme should be
- documented.
+ XXX What is actually needed to verify that it isn't needed?
-Deal with lack of PCGI
+ AAA THe best way to do this is to write a unit test which verifies
+ that the default objects installed into a "new" ZODB when Zope
+ starts are present and working, and their content either matches
+ the content of what would have come from Data.fs.in or is "close
+ enough". The code that installs these default objects exists in
+ the initialize function within lib/python/OFS/Application.
- In the old setup style, "w_pcgi.py" was invoked to install Zope with
- a PCGI ("persistent CGI") socket and files necessary for using Zope
- in conjunction with Apache/IIS. There are no knobs for installation
- right now to do the same thing. The 'pcgi' directory still exists
- in the Zope root dir and the 'make_resource.py' file in "inst" also
- is available, in case we decide to do something with them.
+-----------------
+BEFORE 2.7 FINAL
+-----------------
-Server construction errors need to be better
+Review the Zope Book 2.6 Edition chapters and come up with revisions
+or at least create a Zope Trunk Install HowTo
- When a server is constructed, it attempts to bind to a port. If the
- port cannot be bound, an error is raised. The error currently doesn't
- include the port number, and should.
+ The 2.6 edition Zope Book at
+ http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition has
+ three chapters which detail installation (installing and starting
+ zope), maintenance (maintaining zope) and ZEO (scalability and ZEO).
+ These chapters should be reviewed for inaccuracies with respect to
+ the forthcoming trunk changes and changes should be made "offline"
+ to allow a Zope Book 2.7 edition.
+ At least create a HowTo which summarizes the differences between
+ installing 2.6 and installing the trunk.
------------------------------
MAYBE NEVER BUT NICE TO HAVE
@@ -296,3 +190,27 @@
http://my.zope.com/CPM/CPM/issues/4 and
http://my.zope.com/CPM/CPM/issues/3. Not necessary for merge, but
useful to think about for future.
+
+
+RPM install should recompile .pycs
+
+ The RPM spec file (inst/Zope.spec.in) should delete and recompile
+ .pycs/.pyos during an RPM install to make sure tracebacks contain
+ real Zope filenames instead of filenames relative to the build
+ directory. Alternately the RPM install should not contain .pycs or
+ .pyos.
+
+ XXX Not clear why this is actually needed; importing a module causes
+ the __file__ to be updated with the right filename. A nice touch,
+ but not required.
+
+ AAA Is this a new Python feature or has it always been this way?
+ Tracebacks used to show the location of the .pyc where it had been
+ compiled, not where it actually lived.
+
+RPM install versioning scheme needs to be documented
+
+ The RPM builder has a versioning scheme via the generated Makefile
+ in order to allow for the install of multiple simultaneous versions
+ of Zope on a single system. This versioning scheme should be
+ documented.