[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.