Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 02:47, Guido van Rossum wrote:
I'd like to compare notes on this. Where's the control script that
you are using? I'm hoping that we can use (some future evolution of)
zdaemon/{zdaemon,zdctl}.py in the Zope 2.7 trunk. This separates the
concerns of
- the actual server process (Zope/ZEO/ZRS; for ZEO, this is
runsvr.py)
- a daemon subprocess manager, which restarts the subprocess when it
dies, etc. (zdaemon.py)
- a tool to control the subprocess manager, telling it to
start/restart/stop the server subprocess, etc. (zdctl.py)
This sounds like a good arrangement.
Most of the code for the ctl app that's checked in to the
chrism-install-branch is in lib/python/Controller/ZctlLib.py. A stub
which imports this code is written out to the bin/zctl.py file in an
instance home (after you run configure; make; make instance, for
example).
The pedigree of this code is that it was originally coded up by Tres but
it has been hacked by me since then to support Windows and to support
the loading of configuration data from a config file with matching
command-line parameters (mostly so you can inspect the config file based
environment and pass in --switches that match the names of keys in the
config file). It's not a particularly pretty piece of code and I
wouldn't mind at all seeing it replaced.
* better support for Windows services
I'd like to hear more about this; my zdaemon.py currently doesn't do
Windows at all. Where can I peek at your code?
A file named ntservice.py is written to the bin directory of an instance
home after make instance. To install an NT service based on an
instance, you would call bin/ntservice.py install. There's not much
more to control when it comes to NT services. They don't seem to
require any of the coding that POSIX stuff does to switch effective
users or run in the background, etc. I'm not sure that you can tell an
NT service to restart a process that has died, but probably.
This feature is not wired up to any installer or anything, but it should
be.
* RPM-building support.
* where possible, the banishment of environment variables
as configuration.
All of these things save for the last are more or less complete on
the chrism-install-branch of the Zope trunk. The major missing
piece is the fleshing out of the interaction between the
configuration system (ZConfig) and Zope itself. It works currently
but it needs to be improved and canonized to everyone's liking.
Can you point to where Zope's use of ZConfig is?
chrism-install-branch in lib/python/zope.py and
lib/python/Controller/Main.py. You can sorta see it in action if you
create an instance home using the instructions that come with the branch
and mess around with the config file in etc/zope.conf (put bad keys and
sections in there, misspell things, etc, it should give you a pretty
informative message about where in the config you screwed up).
The sample config file is a little misleading (actually... parts of it
are just plain wrong) as it details an older generation of config file
ideas. I have not had time to regenerate the default config file. The
best place to get an idea of what values are available is the schema for
the Zope config in lib/python/Controller/directives.xml.
Since ZConfig will also used by other ZC software (ZEO, ZRS),
there's a bit of back and forth that needs to be done to get
everybody to agree on a way to do it. Once that is worked out, and
the proposal is cleaned up, I think we can just merge.
Apologies in advance: my refrain seems to be where's your code for
X? -- there's so much good stuff in your branch that I don't know
where to begin, especially not with the Zope part (in ZODB, I know my
way around better).
It's really no problem, I realize how difficult it is to reverse
engineer somebody else's head. Hopefully I can improve the proposal soon
and the vision might get clearer to other folks but me.
I suppose I should add better logging support to this list of features
as well, but since we've already got it going on the trunk and we're
already figuring it out, I won't.
- C
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Weird BTrees/ZODB interaction under Solaris
I made the following reproducable observation running Zope 2.5 under Solaris: I was indexing a CMF site using TextIndexNG with about 1600 objects. During the commit phase (after all objects were indexed), the Zope process grow from about 100MB to more than 1.2GB. I could track this down to TextIndexNG. There is a function written in C that inserts the list of splittet words into the BTrees for the forward and reverse index (by generating the WordIDs internally). Replacing this method with a pure Python implementation made Zope behave fine. Torturing the corresponding C implementation in an isolated environment did not show any memory leaks (neither under Solaris nor under Linux i386). To make it short: my C implementation has three args: the forward index, the reverse index and a list of words to be inserted. The indexes are an OIBTree and an IOBTree. Internally I call PyObject_SetItem() to store the word-wid mapping. This seems to work fine isolated but seems to blow up the ZODB for unknown reasons. Note that his behaviour is only reproducable under Solaris. I made some tests by indexing about 100.000 docs under Linux with TextIndexNG and the Zope memory usage was very fine (up to 150MB). Cheers, Andreas - -Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - -Life is too short to (re)write parsers - - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
Hi Jamie, --On Montag, 25. November 2002 22:29 -0800 Jamie Heilman [EMAIL PROTECTED] wrote: * where possible, the banishment of environment variables as configuration. I have to say, I think this is a bad idea. What is it about environment variables do you find worthy of banishment? I can tell you a few of the reason I really like them: a) Code spent garnering values is minimal, I don't have to worry about acres of code spent parsing yet another config file format or the inevitable quirks and bugs in that code. It doesn't get much simpler than os.environ.get() b) I have tools to examine runtime environments which are external to the zope application and any of its limitations. If I wanna know what a particular value is, I can just find out using ps. I don't have to dig around in the zmi, or rely on any custom clients to query that data from a running instance. c) Environment variables lend themselves to nicely to modification by third party tools; I can set environment variables in shell scripts, python scripts, whatever--the paradigm is language agnostic. In particular I'm rather fond of using daemontools and its envdir program in conjunction with a custom z2.py replacement that lets me take advtanage of the excelent supervision and logging infrastucture provided by daemontools. Force me to use an external config file and its going to make this kind of thing more difficult to do. Oh, while we are at it - how do I set an environment variable in a python script for use outside the script? E.g. like export does in shell scripts? Regards TIno That said I know they aren't an end-all solution for all configuration needs, but just because they don't fit every need I don't see why they should be completely discounted. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Weird BTrees/ZODB interaction under Solaris
I made the following reproducable observation running Zope 2.5 under Solaris: I was indexing a CMF site using TextIndexNG with about 1600 objects. During the commit phase (after all objects were indexed), the Zope process grow from about 100MB to more than 1.2GB. I could track this down to TextIndexNG. There is a function written in C that inserts the list of splittet words into the BTrees for the forward and reverse index (by generating the WordIDs internally). Replacing this method with a pure Python implementation made Zope behave fine. Torturing the corresponding C implementation in an isolated environment did not show any memory leaks (neither under Solaris nor under Linux i386). To make it short: my C implementation has three args: the forward index, the reverse index and a list of words to be inserted. The indexes are an OIBTree and an IOBTree. Internally I call PyObject_SetItem() to store the word-wid mapping. This seems to work fine isolated but seems to blow up the ZODB for unknown reasons. Note that his behaviour is only reproducable under Solaris. I made some tests by indexing about 100.000 docs under Linux with TextIndexNG and the Zope memory usage was very fine (up to 150MB). Could you try again with the C version, substituting a different malloc implementation, or Python 2.3 (which has effectively a different malloc for small blocks)? It could be a semi-bug in the platform malloc where the allocation and deallocation pattern of your test happens to cause worst-case fragmentation. Using Python code probably changes the allocation pattern enough to avoid the fragmentation. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Weird BTrees/ZODB interaction under Solaris
--On Dienstag, 26. November 2002 08:35 -0500 Guido van Rossum [EMAIL PROTECTED] wrote: ... Could you try again with the C version, substituting a different malloc implementation, or Python 2.3 (which has effectively a different malloc for small blocks)? It could be a semi-bug in the platform malloc where the allocation and deallocation pattern of your test happens to cause worst-case fragmentation. Using Python code probably changes the allocation pattern enough to avoid the fragmentation. What do you mean with a different malloc implementation? Currently we are bound to Python 2.1.3 and Zope 2.5.X and we can not upgrade to other Zope/Python versions at least for the installation where I encountered the problem. Andreas - -Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - -Life is too short to (re)write parsers - - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 05:22, Tino Wildenhain wrote: Oh, while we are at it - how do I set an environment variable in a python script for use outside the script? E.g. like export does in shell scripts? Not from a Zope Python Script (it's restricted by the security machinery) but from any other piece of Python: import os os.environ['NAME] = 'VALUE' ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] (Zope 2.6) Buglett in ZODB.ConflictResolution (missing import)
Just stumbled across a traceback in the logs that looks like a small bug in ZODB.ConflictResolution. In line 81 there's a reference to sys.exc_info() but sys is never imported in this module. Jo. -- Internetmanufaktur Jo Meder -- Berlin, Germany http://www.meder.de/ --- fon: ++49-30-417 17 63 33 Kollwitzstr. 75 fax: ++49-30-417 17 63 45 10435 Berlin --- mob: ++49-170- 2 98 89 97 Public GnuPG-Key -- http://www.meder.de/keys/jo-pubkey.txt ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
Hi, --On Dienstag, 26. November 2002 09:18 -0500 Chris McDonough [EMAIL PROTECTED] wrote: On Tue, 2002-11-26 at 05:22, Tino Wildenhain wrote: Oh, while we are at it - how do I set an environment variable in a python script for use outside the script? E.g. like export does in shell scripts? Not from a Zope Python Script (it's restricted by the security machinery) but from any other piece of Python: import os os.environ['NAME] = 'VALUE' Tried it: os.environ['MYENVIRON']='FooBar' ^D echo $MYENVIRON nothing. What is wrong? Regards Tino ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 26 Nov 2002, Tino Wildenhain wrote: Tried it: os.environ['MYENVIRON']='FooBar' ^D echo $MYENVIRON nothing. What is wrong? rdmurray@stage:~cat temp.sh export TEST='abc' echo $TEST rdmurray@stage:~sh temp.sh abc rdmurray@stage:~echo $TEST ^ equally nothing. export (and the equivalent python above) sets the environment variable in the current process environment space, *not* the parent (that's a *much* trickier operation). The obverse (TEST='abc' somecommandhere) sets the environment variable only in the *sub*process environment space (the one being created) and does not affect the current process. The python equivalent of *that* would be to supply a modified *copy* of the ENVIRON dict to execve or similar. To do the python equivalent of what happens when you set a variable in a script *without* using export (the current process environment is changed but the change is not passed to subprocesses), you'd have to make a copy of the environ before modifying it, and pass *that* to execve or equivalent. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 10:39, Jeffrey P Shell wrote: * configure; make; make install installation I thought that there was an effort to use distutils, or to at least use a distutils-ish setup. What happened to that? It does use distutils, owing to the work of Matt Behrens and Shane on the setup.py file. The configure; make stuff just wraps distutils to a large degree. I gather from reading other posts that this is a different format than Zope 3's ZCML. Would it be worth it to at least make some sort of 'ZCML Lite' to do this sort of configuration? The main thing I'm concerned about is that there's a whole new Zope coming down the road that depends heavily on configuration files, and it might make sense to start weaning people onto its general syntax if Zope 2's finally going to have a config file. As other folks mentioned, we made a conscious decision to not have an XML config file format. That said, the schema (the allowable values and sections) of the config file may be in XML and might even use ZCML (if I can figure it out). I have been paying attention to RDM's checkins to the metameta stuff on the Zope 3 branch, but I still haven't quite figured out how to use ZCML for this purpose. I've got a homebrew solution that does use XML now. Anyways - good work. The better support for Windows services alone would get you a beer if I happened to be on that coast.. :) Thanks! Cheapskate. I think you owe me at least two other beers anyway. ;-) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
Currently you configure Zope via a combination of z2.py switches and envvars. There are currently 40 Zope environment variables and 22 z2.py switches. Well you won't hear a peep out of me if z2.py gets the axe, as I mentioned I stopped using it long ago in favor of something that was only 39 lines and only did exactly what I needed and nothing more. I feel that it's just as simple (or maybe simpler) to look in a config file. The Zope config file will be stored on the filesystem (not in the ZODB), and it's in a format much like an Apache config file, so no ZMI or custom client stuff will be necessary. There will be tools provided to parse the config file if necessary. Yes, but config files lie about the _running_ configuration. They can be changed without the process being restarted. Actually environment variables can fall prey to the same issue if they are simply looked at once, stuck in a local variable and then that local variable is later modified, but that isn't as common in my experience. If you have ideas about what should (and should not) be done wrt canonizing a config file for Zope, please detail specifics here as nothing is set in stone. I suppose, as movement in this direction is imminent, what I can probably get away with doing is just hooking all my custom environment variable stuff into the configuration machinery at startup. But thats assuming that once the configuration file is parsed the results are bundled into a single data structure that is then globally available to the rest of the zope machinery. As I haven't looked at the cvs branch in question perhaps you could tell me how valid this assumption is. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 11:28, Jamie Heilman wrote: Well you won't hear a peep out of me if z2.py gets the axe, as I mentioned I stopped using it long ago in favor of something that was only 39 lines and only did exactly what I needed and nothing more. z2.py is a dead man walking. ;-) I suppose, as movement in this direction is imminent, what I can probably get away with doing is just hooking all my custom environment variable stuff into the configuration machinery at startup. But thats assuming that once the configuration file is parsed the results are bundled into a single data structure that is then globally available to the rest of the zope machinery. As I haven't looked at the cvs branch in question perhaps you could tell me how valid this assumption is. It currently works this way, but the location of the configuration(s) need to be canonized. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
CM == Chris McDonough [EMAIL PROTECTED] writes: * configure; make; make install installation I thought that there was an effort to use distutils, or to at least use a distutils-ish setup. What happened to that? CM It does use distutils, owing to the work of Matt Behrens and CM Shane on the setup.py file. The configure; make stuff just CM wraps distutils to a large degree. And configure; make; make install is a worth goal. From a sysadmin's point of view, they're already conditioned to doing this to install open source software, so under the Pinball Machine Principle, when they see one in Zope, they'll run that first before reading (the whole) README file. Low barrier of entry is a good thing! -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Weird BTrees/ZODB interaction under Solaris
Andreas Jung writes: ... Internally I call PyObject_SetItem() to store the word-wid mapping. PyObject_SetItem creates new references for key and value. Is this what you expect? I know, this should affect all platforms and be independent of whether or not the code runs within or outside Zope. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
Chris McDonough writes: On Mon, 2002-11-25 at 20:42, [EMAIL PROTECTED] wrote: Could we get the Install and Configuration proposal cleaned up, with so many comments it's not clear what the actual proposal proposes to deliver now. Yes when possible. I agree that it is a bit of a mess. In the meantime, I think this list summarizes the adjusted goals well: ... * where possible, the banishment of environment variables as configuration. Please do not! They are used for it now. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 13:56, Dieter Maurer wrote: * where possible, the banishment of environment variables as configuration. Please do not! Do not what? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MailHost from 2.5.1 does not work in 2.6.0
... moving discussion from [EMAIL PROTECTED] to [EMAIL PROTECTED] Actually the topic has been that the smtp_port attribute of a MailHost has changed type from string in 2.5.1 to int in 2.6.0 I guessed a little hint about this incompatibility in the release notes would have been nice, but I can find nothing in this regard. I don't think anybody really was aware of it... :-/ It has to be fixed to 2.6.1 of course. The question is: Should the fix be to cast the smtp_port into an int every use (simple, functional, safe, ugly) or something else? Personally I guess it would be enough if there would be a notification that one should update the MailHost instances after upgrading. It is really easy; push the save button of the Edit tab fixes the issue without ado. That's actually very easy, and could be simulated by some script if one has more than N MailHost instances in one Zope instance (where N depends ones patience when clicking through the ZMI ;-) OTOH, there is exactly one place, where the smtp_host atrribute is used; lib/python/Products/MailHost/MailHost.py, line 214ff: security.declarePrivate( '_send' ) def _send( self, mfrom, mto, messageText ): Send the message smtpserver = SMTP( self.smtp_host, self.smtp_port ) # -- here smtpserver.sendmail( mfrom, mto, messageText ) smtpserver.quit() Thus if one does not trust people to read release notes, one could pragmatically add the int(...) cast here to avoid traffic on [EMAIL PROTECTED], though the cast is superfluous most of the time. [...] I checked some history. Up to 2.4 it was stored as an integer. For some reason it was changed between the final 2.5 beta and 2.5 release to be stored as a string, and then cast into an integer each time it was used. I don't know the rationale behind this change. [...] Well, if the change in 2.6.0 is actually a change _back_ to an old type, and nobody has complained about the change in 2.5, then it is maybe an unlucky accident Jan Ulrich Hasecke and me have created MailHost in 2.5.1, and everybody else will simply skip over this without notice. In this case my reply is too long already ;-) cheers, clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope] MailHost from 2.5.1 does not work in 2.6.0, was: Script from 2.5.1 does not work with 2.6.0
From: Clemens Robbenhaar [EMAIL PROTECTED] I guessed a little hint about this incompatibility in the release notes would have been nice, but I can find nothing in this regard. I don't think anybody really was aware of it... :-/ It has to be fixed to 2.6.1 of course. The question is: Should the fix be to cast the smtp_port into an int every use (simple, functional, safe, ugly) or something else? Did I miss some place to look at, or should the release notes possibly be improved with respect to this? I checked some history. Up to 2.4 it was stored as an integer. For some reason it was changed between the final 2.5 beta and 2.5 release to be stored as a string, and then cast into an integer each time it was used. I don't know the rationale behind this change. However, the current MailHost is first appeared as a fix for several header problems I had already back in Zope 2.3, and this is probably why this change between 2.4 and 2.5 wasn't caught by the 2.6 MailHost. I based it on a 2.5 beta MailHost and must simply have missed this change, or at least not realized the effects of it. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
I have updated this proposal to be in line with the current goals: http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration Thanks for poking me, - C On Mon, 2002-11-25 at 20:42, [EMAIL PROTECTED] wrote: Hi Could we get the Install and Configuration proposal cleaned up, with so many comments it's not clear what the actual proposal proposes to deliver now. Also parts of it's problem statement are just plain wrong. I currently have many (read every version of Zope including Alpha's and Betas since 2.4.1b1) installed on the same box, and I have 18 instances of which at least 8 are running concurrently on our dev box, currently using at least 2 different versions of Zope (2.5.1 and 2.6.0). (Some of the non running instances if I started them up would be on 2.4.3 etc.. Currently we can do everything listed as a problem in the proposal, it is clean, neat and everything is in it's place. (except maybe item 5 in the problem statement) Regards Tim On Tue, 2002-11-26 at 04:12, Brian Lloyd wrote: Is there already a schedule for Zope 2.7? (of course there is not :-) ) Now there is :) http://dev.zope.org/Wikis/DevSite/Projects/Zope2.7/FrontPage I've updated this project and tried to dispel any lingering confusion over the earlier effort labelled Zope 2.7. I proposed to include reStructuredText into Zope 2.7. This stuff is ready to be merged. If there are no objections I will merge it soon since there were only positive votes for the inclusion. Please don't merge anything until people have had a chance to see what's going on and gotten the plan finalized. Per the plan above, I'd like for there to be a (relatively short) period for people to volunteer and add proposals to the plan, followed by a process of prioritizing and coming to closure on what will / won't be included. I propose in the wiki that we should probably schedule an IRC day to do that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) DISCLAIMER: This email, including any attachments, is intended only for use by the addressee(s) and may contain confidential and/or personal information and may also be the subject of legal privilege. Any personal information contained in this email is not to be used or disclosed for any purpose other than the purpose for which you have received it. If you are not the intended recipient, you must not disclose or use the information contained in it. In this case, please let me know by return email, delete the message permanently from your system and destroy any copies. Emails and their attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. All attachments are opened at the recipient's risk. ___ Zope-Coders mailing list [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-coders ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
