Re: [Zope] What causes the community to stall so often?
I am not sure if it is the community stalling so much as hitting the peaks and valleys of the development cycle. Besides, the Zope Corp people I am sure that most of us have full time (or at least part time) jobs that are non Zope. I have had mostly-full time Zope jobs and when I was doing that I was more involved in writing tips, how-tos, products, etc. I think Zope documentation (not the Zope product) suffers from the critical mass. There has to be enough people in the pot to be able to both develop and document. Right now, most of us are focusing on developing products, applications, websites and not on documentation. It is also clear that documentation itself does not provide income. If I build out another website in Zope, I can build a community and another revenue source. If I write a how-to, well, I get a gold star in the community (maybe) and it that good open source "warm feeling." So, it comes down to economics. That being said, there are now 3 (maybe 4) books out there on Zope and I can easily remember the day when there was a total of 0. There are more and more products being developed and not just stupid discussion boards :) but real, meaty products that people can make money with. That trend is a good trend. As the economy picks back up, there will be more work for consultants, more consulting and more demand and production of documentation. Do we need more books, websites, help areas, FAQ's, etc? Yes. Will they come? Yes. I have at least two of those in (not telling which ones) in the works. But time is money and money is the key. BZ
Hi, I am a newcomer in Zope (been using it for a week), coming from PHP. My view of Zope is still fresh. I am a very experienced Linux admin from the ISP world, but also a C programmer. I think Zope has the following problems: 1. difficult installation (What? you say? I'll come to that) 2. unclear direction 3. downloadable productlist 'unreliable' 4. small but showstopping documentation deficiences 1. Difficult installation. Most people want to install a binary package these days (in practice this means RPM). When you look at the downloads, you see that the latest RPM is not the most recent Zope version. Oops! I thought, is this a serious product? (Please note: this first impression is important) Another thing: how to install? PCGI? ZServer? There is no recommended way. Documentation is sparse on this matter. The windows install is good, but you're missing most of the opensource community if the unix/linux people don't install zope. And many people *only* install rpm (if only for easy removal). 2. Unclear direction. When I started browsing www.zope.org and all the dopcumentation, I came about three confusing differences: DTML, ZAL, and Zope3. It all was unclear to me, and if I will build a site in Zope I don't want to be on a dead trail. It is unclear to me which route I should take. 3. downloadable product list. Many products I downloaded did not work with my zope 2.5.0. ZopeGUD is broken. I could not even create an RPM for ZMySQLDA, even though I asked around on this list. So I still don't have MySQL access. Other products are listed as unmaintained. Why are they still on the list? Also there are duplicate products. The difference between them is not outlined, and nothing is recommended. Are some products far superior to others even though they seem to accomplish the same thing? I am forced to find out myself. 4. small documentation deficiences. Small things that stop you dead in your tracks. I can provide examples. Basically what I miss is a clear path to take, many recommendations (PHP has lots of those) easy RPM installation, and a bag of working trustworthy Products (preferably distributed as RPM's). regards, Ron Arts -- Netland Internet Services bedrijfsmatige internetoplossingen http://www.netland.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281
From: "Ron Arts" <raarts@netland.nl>
Most people want to install a binary package these days (in practice this means RPM).
Is this really true? When I install things on unix, I usually download and unzip a tgz file, run ./configure, write "make" and "make install", and I'm done. This is a couple of more steps than installing a binary package, it's true, but I have in several cases ended up removing the binary package and compiling from scratch, because the package by some reason doens't work, while the default configure and make of the source does. I don't know why this is, it just is. Maybe I'm unique in this, but don't find it very complicated to install software this way. And Zope's installation is even fewer steps. Granted, it's not ./configure and make, it's python w(o)_pcgi.py, but it still less steps... :-)
Another thing: how to install? PCGI? ZServer? There is no recommended way. Documentation is sparse on this matter.
Eh, no, becuase it depends on if you are using PCGI or not. If you are, run w_pcgi.py, if you aren't run wo_pcgi.py. Thats it...
The windows install is good, but you're missing most of the opensource community if the unix/linux people don't install zope. And many people *only* install rpm (if only for easy removal).
I think deleting a directory is easier. Your other points are completely valid, however.
When I started browsing www.zope.org and all the dopcumentation, I came about three confusing differences: DTML, ZAL, and Zope3. It all was unclear to me, and if I will build a site in Zope I don't want to be on a dead trail. It is unclear to me which route I should take.
Zope 3 is not a "route". You can't take it. Until version 3 exists, you shouldn't try use it. If this is unclear, it's very bad. You shouldn't even know about Zope 3 unless you go to dev.zope.org. How did you get the impression that Zope 3 is a route to take when using Zope today? When it comes to DTML vs ZPT I think the Zope book is rather clear on what the differences are.
On Fri, Mar 08, 2002 at 06:53:01PM +0100, Lennart Regebro wrote:
From: "Ron Arts" <raarts@netland.nl>
Most people want to install a binary package these days (in practice this means RPM).
Is this really true?
Yes.
When I install things on unix, I usually download and unzip a tgz file, run ./configure, write "make" and "make install", and I'm done.
That because you manage only one computer. Think about poor sysadmins who maintain dozens servers on a site - they just don't have enough time to untar and compile all that crap... Oleg. -- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
At 08.03.2002 22:15 +0300, Oleg Broytmann wrote:
On Fri, Mar 08, 2002 at 06:53:01PM +0100, Lennart Regebro wrote:
When I install things on unix, I usually download and unzip a tgz file, run ./configure, write "make" and "make install", and I'm done.
That because you manage only one computer. Think about poor sysadmins who maintain dozens servers on a site - they just don't have enough time to untar and compile all that crap...
OTOH my admins would never use (mission critical) rpms they did not carefully package themselves... :-) Stefan
On Fri, 8 Mar 2002, Stefan H. Holek wrote:
At 08.03.2002 22:15 +0300, Oleg Broytmann wrote:
On Fri, Mar 08, 2002 at 06:53:01PM +0100, Lennart Regebro wrote:
When I install things on unix, I usually download and unzip a tgz file, run ./configure, write "make" and "make install", and I'm done.
That because you manage only one computer. Think about poor sysadmins who maintain dozens servers on a site - they just don't have enough time to untar and compile all that crap...
OTOH my admins would never use (mission critical) rpms they did not carefully package themselves... :-)
Yeah, well. I remember the line in "Essential System Administration" (O'Reilly) about never installing as root a product that you haven't carefully studied the source code for, looking for security vulnerabilities. All I thought was: wow, people must have a lot more free time on their hands than I do! Ever tried reading the source code for perl? :-) But, seriously, I'm curious: do you think that you're getting better security w/someone's ./configure && make && make install setup (also run as root, can also execute anything you want and might unless you read the configure file and make file and source code)? -- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant
Joel Burton wrote:
But, seriously, I'm curious: do you think that you're getting better security w/someone's ./configure && make && make install setup (also run as root, can also execute anything you want and might unless you read the configure file and make file and source code)?
No, but I for one think I get better stability. Quite now I expiriencing segmentation faults on a server which has been updated with new php rpms from the distribution vendor, without any conflicts, and the apache process segfaults everytime php wants to write to a mysql database. SRPMS, that perhaps would be another case .... cheers, oliver
On Fri, 8 Mar 2002, Oliver Bleutgen wrote:
Joel Burton wrote:
But, seriously, I'm curious: do you think that you're getting better security w/someone's ./configure && make && make install setup (also run as root, can also execute anything you want and might unless you read the configure file and make file and source code)?
No, but I for one think I get better stability. Quite now I expiriencing segmentation faults on a server which has been updated with new php rpms from the distribution vendor, without any conflicts, and the apache process segfaults everytime php wants to write to a mysql database.
SRPMS, that perhaps would be another case ....
I see. Non-maintainers always forget about SRPMS. Distributing it gives many of the advantages of the RPM, but you can compile for your site. -- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant
On Fri, Mar 08, 2002 at 09:25:08PM +0100, Stefan H. Holek wrote:
OTOH my admins would never use (mission critical) rpms they did not carefully package themselves... :-)
I envy. They have a lot of spare time. I don't. Oleg. -- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
-> That because you manage only one computer. Think about poor sysadmins who -> maintain dozens servers on a site - they just don't have enough time to -> untar and compile all that crap... It's much more than just ease of installation. If "./configure, make, make install" did the valuable things RPM did for me, I wouldn't use RPM. RPM is system-wide version control. 'Pristine' sources. A safe upgrade path. An established method for handling dependencies. A way to verify that the files have not been tampered with. A quick way to see what is or is not installed on a particular system. A way to identify the purpose of any little file on your hard drive. A way to CLEANLY uninstall something. Depending on "make uninstall" is dangerous; it assumes that the admin knows (a) all packages on a particular system, and (b) all dependencies between those packages. Not exactly a good idea for a production environment. (It also requires you to keep a turd of a build directory lying around, but that's just an annoyance.) Also, having a C compiler on a production server is dangerous, as it gives script kiddies the ability to run the shell script they downloaded and wind up with a rootkit on your system. RPMs avoid that vulnerability. (Not that it can't be worked around... I'm referring to unskilled punks.) Operating Systems come with package management systems for a reason. It's one thing for me to futz around on my workstation, but in a production environment -- where you don't know who is using which systems for what purposes -- RPM (or DEB, or to a much lesser degree pkginstall or the 'ports' system) is an invaluable tool. --Derek
From: "Oleg Broytmann" <phd@phd.pp.ru>
That because you manage only one computer.
1. No I don't. Don't make assumptions about people you know nothing about. 2. The more computers you manage the less hassle it is. If you install Zope once and only once, you may start with looking for an RPM. In that case it's a drawback that there isn't one, since you are looking for it. But once you have installed Zope one time, you will then know how easy it is, and the next installation takes no time at all.
Think about poor sysadmins who maintain dozens servers on a site - they just don't have enough time to untar and compile all that crap...
Firstly, most of the time you manage not only several computers, but several websites on each computer. Most of the times you are then not using a standard install anyway, and thereby you would not be able to use an RPM even if you wanted to. An RPM assumes a certain type of install, and in the Zope case that would mean doing exactly the same thing as wo_pcgi.py does. Secondly, "untar and compile all that crap" does not take any longer than it takes you going to an RPM archive to see if there is a Zope RPM, downloading it and installing it. From: "Derek Simkowiak" <dereks@realloc.net>
RPM is system-wide version control. 'Pristine' sources.
How can it be more pristine that getting the source from the manufacturer and compiling it?
A safe upgrade path.
How does this become more safe with RPM's? If a new version is incompatible with your data somehow, it will be incompatible no matter how many RPMs you throw at it.
A way to CLEANLY uninstall something.
As said before: rm -r does that for Zope. And it only depends on you having the correct version of Python. Making binary distributions of any kind is a huge pain in the ass. What operating systems and version do you think Zope should have packages for? How many would that amount to? Zope installes with such an amazing ease that you get very few benefits from having a binary install. Instead somebody (and it seems to me that you guys think it is Zope corp ) has to maintain and test a ton of binary installations for several different version of several different operating systems. There are loads of better things to use that time to. If you so badly want an RPM for just the incarnation of the operating system that you are using: Go ahead, create one. If it's easy to do, then it's not a problem, right? If it is a complicated task, then you realize why it isn't done. But don't tell others that they should put down loads of time into something that very few people will find particularily useful. There are reasons most people that create binary installs for a software aren't connected to the people making the software. They simply have better things to do. From: "Adam Manock" <abmanock@earthlink.net>
The bad news: The install sticks much closer to the default install than previously, effectively undoing a lot of the good restructuring work done in earlier RPM releases.
There went the so called "safe upgrade path". :-)
The "throw everything in either /usr/share/zope or /var/zope" install is definitely not pretty (or FHS compliant). There is no "make install" equivalent functionality that puts stuff where it should be, IMHO this should be done by wo_pcgi, or distutils anyway, not by a monster 1000+ line spec.
Thats because things are *exactly* where they should be after you have unpacked the tarball, unless you want to run multiple servers from the same zope-code, in which case there really doesn't seem to be any One Right Way to do it. Zope does not install like most unix software. It does not consist of a couple of exe files and a few configuration files in an obscure format. For that reason, there is no place where each file *should* be. There is no obvious way to split a Zope installation and spread the files in fifty different places as most installations of many other unix softwares unfortunately do. I suspect this is some of the reson for the great craving for RPM's. People simply do not realize that Zope installs much more easily and much more cleanly than most unix softwares. They don't realize that RPM's for Zope in most cases are more work than non-RPM installs.
On Fri, Mar 08, 2002 at 10:50:55PM +0100, Lennart Regebro wrote:
From: "Oleg Broytmann" <phd@phd.pp.ru>
That because you manage only one computer.
1. No I don't. Don't make assumptions about people you know nothing about.
I don't. During my life I saw it many times - beginner sysdmins do configure-make a lot. Experienced (and busy) sysadmins use ready-made packages - RPM/DEB/PKG on Linux (and Solaris), ports on *BSD.
2. The more computers you manage the less hassle it is. If you install Zope once and only once, you may start with looking for an RPM. In that case it's a drawback that there isn't one, since you are looking for it. But once you have installed Zope one time, you will then know how easy it is, and the next installation takes no time at all.
But Zope is not easy to install. I must: 1. Recompile python with threads and all neccessary modules. 2. Install MySQL, MySQLdb and ZMySQLDA (or Postgres and its DA). 3. Install and run Zope. 4. Modify system's startup scripts. 5. Setup Data.fs (import Products and ZClasses, configure, etc). 6. Modify Apache's config (to make it connect to Zope). Ready-made binary packages with all interdependencies make it MUCH simpler and faster.
From: "Derek Simkowiak" <dereks@realloc.net>
RPM is system-wide version control. 'Pristine' sources.
How can it be more pristine that getting the source from the manufacturer and compiling it?
Because I need to get sources from a dozen of developer sites and compile them in a compatible manner. RMP/DEB automate these tasks. What is more, someone (Debian developers, as I personnaly use Debian GNU/Linux) already tested their compatibility, and provided neccessary binary and configuration files.
A way to CLEANLY uninstall something.
As said before: rm -r does that for Zope. And it only depends on you having the correct version of Python.
No. You have to unmodify system startup scripts (at least). Oleg. -- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
From: "Oleg Broytmann" <phd@phd.pp.ru>
I don't. During my life I saw it many times - beginner sysdmins do configure-make a lot. Experienced (and busy) sysadmins use ready-made packages - RPM/DEB/PKG on Linux (and Solaris), ports on *BSD.
This is quite simply, complete and utter bullshit. Sorry.
But Zope is not easy to install. I must:
1. Recompile python with threads and all neccessary modules.
Well, didn't you have a beloved RPM for that? RPM's are supposed to fix everything, right?
2. Install MySQL, MySQLdb and ZMySQLDA (or Postgres and its DA).
No, you don't need to install this.
5. Setup Data.fs (import Products and ZClasses, configure, etc). 6. Modify Apache's config (to make it connect to Zope).
Ready-made binary packages with all interdependencies make it MUCH simpler and faster.
These two last things can not be done by any RPM. You will have to do that manually, no matter what. Yes, Zope is too hard to get started with. That is quite true. That there are no RPM's are not a part of that problem.
Is it just me, or is "boyish public pissing contents among system adminstrators over rpm vs. no rpm, vi vs. emacs, linux vs. bsd, etc." one possible answer to the question posed by the subject? It's easy, everyone: some of us like RPMs and want to use them. Some of us don't. If you like them, you're probably frustrated that there aren't always modern RPMs for Zope. If you don't like them, you probably don't care. In any event, I think a number of people have suggested that, yes, they'd really like RPMs. Trying to impress us about how many mainframes you've run without using RPMs isn't an answer to their problem. ;-) So, someone has a SRPM for Zope 2.5.0. Who can turn this into good RPMs for common Linux distros? Cheers! -- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant
Lennart Regebro wrote:
From: "Oleg Broytmann" <phd@phd.pp.ru>
I don't. During my life I saw it many times - beginner sysdmins do configure-make a lot. Experienced (and busy) sysadmins use ready-made packages - RPM/DEB/PKG on Linux (and Solaris), ports on *BSD.
This is quite simply, complete and utter bullshit. Sorry.
Well, I will not comment on your tone of voice (oops, i'm sorry, I just did it), I'd like to say the following: 1. I am a fulltime unix administrator since 1993, call me experienced. 2. I am very busy. 3. I *highly* prefer RPM over './configure;make;make install' The last one because we do not install compilers on production servers due to security reasons. This makes the 'configure;make' step rather cumbersome as I have to translate C into hex assembly instructions by hand. So there is at least 1 experienced and busy sysadmin in the world that uses RPM. So it cannot be _complete_ and _utter_ bullshit. Maybe it's _incomplete_ and _almost utter_ bullshit.
Install MySQL, MySQLdb and ZMySQLDA (or Postgres and its DA).
No, you don't need to install this.
Let me quote from the zope book:
MySQL MySQL is a fast open source relational database. You can find more information about MySQL at the MySQL web site. The MySQL DA is maintained by Zope community member Monty Taylor.
Well, the time I spent on trying to install it (and later making an RPM for it) was wasted then?
5. Setup Data.fs (import Products and ZClasses, configure, etc). 6. Modify Apache's config (to make it connect to Zope).
These two last things can not be done by any RPM. You will have to do that manually, no matter what.
'Not be done by any RPM?' You obviously know little about what RPM's can and cannot do. Please be informed in your answers, and don't try to put down others. Ron Arts
From: "Ron Arts" <raarts@netland.nl>
1. I am a fulltime unix administrator since 1993, call me experienced. 2. I am very busy. 3. I *highly* prefer RPM over './configure;make;make install'
So there is at least 1 experienced and busy sysadmin in the world that uses RPM. So it cannot be _complete_ and _utter_ bullshit. Maybe it's _incomplete_ and _almost utter_ bullshit.
Well, experienced, you are welcome to quote the phrase where I said that there are no experienced unix sysadmins that prefer RPMs.
Let me quote from the zope book:
MySQL MySQL is a fast open source relational database. You can find more information about MySQL at the MySQL web site. The MySQL DA is maintained by Zope community member Monty Taylor.
This is all correct. You are now welcome to explain to me exactly where in the above sentences it sais that installing mySQL is a prerequisite for installing Zope.
5. Setup Data.fs (import Products and ZClasses, configure, etc). 6. Modify Apache's config (to make it connect to Zope).
These two last things can not be done by any RPM. You will have to do that manually, no matter what.
'Not be done by any RPM?' You obviously know little about what RPM's can and cannot do.
Ah, sorry, I didn't know RPM's could read your mind, make an informed guess on what port you want your zope zerver to run on, set up your apache configuration so that the correct domain name (which the RPM reads from the notes in your wallet) is proxied to your zope installation and then design and install the webpage for you. Since this obviously is the case, I retract everything I have said in this thread. There should be an RPM for Zope. It could create the verisoning system we want for EasyPublisher for me. We did outline it on the whiteboard last week, so it would be no problem for the RPM to implement it. No, seriously, you can't have an RPM configure the Data,fs and install the correct products for you. If you with point 5 above mean the thing Zope does everytime it's started without a Data.fs, it seems rather useless to have the RPM do that, don't you think? And no, it can't do point 6, unless the RPM magically know exactly which domain names you are going to use and exactly which zope paths you want these proxied to.
Please be informed in your answers, and don't try to put down others.
I am informed, and I do try not to put down others. Sometimes I find this last part extremely difficult.
Ron Arts writes:
... The last one because we do not install compilers on production servers due to security reasons. This makes the 'configure;make' step rather cumbersome as I have to translate C into hex assembly instructions by hand. We do not either...
We generate Zope on a development machine, test it there and when everything is accepted, we pack it together with other third party and our own products and transfer it to all affected production servers. The aim is that the production servers have exactly the same configuration than what has been tested on the development machine. I do not want to claim that RPM may not be useful, though. Dieter
Dieter Maurer wrote:
Ron Arts writes:
... The last one because we do not install compilers on production servers due to security reasons. This makes the 'configure;make' step rather cumbersome as I have to translate C into hex assembly instructions by hand. We do not either...
We generate Zope on a development machine, test it there and when everything is accepted, we pack it together with other third party and our own products and transfer it to all affected production servers. The aim is that the production servers have exactly the same configuration than what has been tested on the development machine.
I do not want to claim that RPM may not be useful, though.
Right. That's what we do. We manage a couple of hundred secured servers in more than hundred different locations using RPM. All servers need to contain *exactly* the same software to ease management. We only allow RPM's on those machine, I think it's the only way we can be *sure* they contain exactly the same setup, we can install a new server really quick. I don't say there aren't any other ways but for our setup it works really well. Ron Arts
On Sat, Mar 09, 2002 at 01:07:28AM +0100, Lennart Regebro wrote:
From: "Oleg Broytmann" <phd@phd.pp.ru>
I don't. During my life I saw it many times - beginner sysdmins do configure-make a lot. Experienced (and busy) sysadmins use ready-made packages - RPM/DEB/PKG on Linux (and Solaris), ports on *BSD.
This is quite simply, complete and utter bullshit. Sorry.
These harsh words indicate that you are out of resonble arguments. I said "I saw many times" - and this is my experience, which is reasonable argument. You can use counterarguments. But if you just want to argue without reasonable arguments - that is, attack me - I can easily ignore you, either manually, or using killfile. No problem for me.
But Zope is not easy to install. I must:
1. Recompile python with threads and all neccessary modules.
Well, didn't you have a beloved RPM for that? RPM's are supposed to fix
Yes, they did - that why I prefer them.
everything, right?
Wrong. Sarcasm ignored.
2. Install MySQL, MySQLdb and ZMySQLDA (or Postgres and its DA).
No, you don't need to install this.
Zope without SQL is just a toy for small sites.
5. Setup Data.fs (import Products and ZClasses, configure, etc). 6. Modify Apache's config (to make it connect to Zope).
Ready-made binary packages with all interdependencies make it MUCH simpler and faster.
These two last things can not be done by any RPM. You will have to do that
Why?
manually, no matter what.
Wrong. Oleg. -- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Sat, 9 Mar 2002, Oleg Broytmann wrote:
2. Install MySQL, MySQLdb and ZMySQLDA (or Postgres and its DA).
No, you don't need to install this.
Zope without SQL is just a toy for small sites.
I disagree with this in the most stringent way possible. An RDB is not needed for large sites and going with an OODB is not a toy. I do take offense to you considering the ZODB to be a toy. I think it does need some more capabilities then it has now but it no way is it a toy. Especially not compared to MySQL. Actually in many cases an OODB will outperform an RDB depending on the application model used. If you already have data in an RDB I can see why you want to hook zope to it or you need data in another application that can only speak to an RDB I can see why you would want to use it. However if you don't have those requirements there is no reason to tie yourself to an RDB.
Hi, I created a Zope 2.5.0 SRPM, and a ZMySQLDA SRPMS. I wanted to share them with others by uploading them to my personal Zope area on www.zope.org as a software product. But instead of uploading the system waits, and after a while shows the login popupbox. Is this expected behaviour? Ron Arts
We had a problem with warez folks using zope.org for distributing pirated software. Thus, you have to be given a special role to upload something larger than 250Kb (I believe that's the limit). If you'd like this role, send a note to zope-web and we'll gladly do so. I'm about to follow up to Adam's note regarding the production of RPMs as part of the standard build/release process. Ron, can you participate as well? --Paul Ron Arts wrote:
Hi,
I created a Zope 2.5.0 SRPM, and a ZMySQLDA SRPMS. I wanted to share them with others by uploading them to my personal Zope area on www.zope.org as a software product.
But instead of uploading the system waits, and after a while shows the login popupbox.
Is this expected behaviour?
Ron Arts
Actually - to make this "the-biggest-thread-today-and-forever" I may want to add some other arguments of tieing (tying?) to an RDB (especially compared to ZODB, not other ODBs): - Data integrity checks and - Data constraints - Customer wish (you can't argue to your customer to be better then oracle e.g. if they don't like to argue. They will just leave off to your competitors) These are only two (i remember there were some more) that are more tied to the application itself, rather than its circumstances to live in, but although I wouldn't even try to speak about "a toy" when talking about zope, which lets me create very fast and stable applications based on RDBs. (I really like the way to put queries into their own objects.) my two euro cents. On Sat, Mar 09, 2002 at 04:42:54AM -0700, kosh@aesaeion.com wrote:
On Sat, 9 Mar 2002, Oleg Broytmann wrote:
2. Install MySQL, MySQLdb and ZMySQLDA (or Postgres and its DA).
No, you don't need to install this.
Zope without SQL is just a toy for small sites.
I disagree with this in the most stringent way possible. An RDB is not needed for large sites and going with an OODB is not a toy. I do take offense to you considering the ZODB to be a toy. I think it does need some more capabilities then it has now but it no way is it a toy. Especially not compared to MySQL. Actually in many cases an OODB will outperform an RDB depending on the application model used.
If you already have data in an RDB I can see why you want to hook zope to it or you need data in another application that can only speak to an RDB I can see why you would want to use it. However if you don't have those requirements there is no reason to tie yourself to an RDB.
-- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
Zope without SQL is just a toy for small sites.
I need to take exception to this. We help maintain some high-profile and high-traffic websites that have no connection whatsoever to a SQL database. ZEO makes this very possible. -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
Chris McDonough wrote:
Zope without SQL is just a toy for small sites.
I need to take exception to this. We help maintain some high-profile and high-traffic websites that have no connection whatsoever to a SQL database. ZEO makes this very possible.
Agreed. I like Jim's take on SQL ;-) Chris
On Sat, Mar 09, 2002 at 02:24:20PM -0500, Chris McDonough wrote:
Zope without SQL is just a toy for small sites.
I need to take exception to this.
No problem. There are rules, and there are exceptions :) Oleg. -- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Sat, 2002-03-09 at 12:24, Chris McDonough wrote:
Zope without SQL is just a toy for small sites.
I need to take exception to this. We help maintain some high-profile and high-traffic websites that have no connection whatsoever to a SQL database. ZEO makes this very possible.
I have to agree, I have several Intranet sites that have been far from "small sites". We in fact, moved away from ZSQL. -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).
-> > RPM is system-wide version control. 'Pristine' sources. -> -> How can it be more pristine that getting the source from the manufacturer -> and compiling it? It can be more pristine by having checksum, filesize, and public key signature checks to verify that you're using the source EXACTLY as distributed by the 'manufacturer'. I.e., who knows whether or not that mirror you just downloaded from has a respectable admin... RPM does this automatically for me, instead of me having to do it myself manually. -> > A safe upgrade path. -> -> How does this become more safe with RPM's? If a new version is incompatible -> with your data somehow, it will be incompatible no matter how many RPMs you -> throw at it. I was not referring to data compatibility. What you say above is obvious. I was referring to (a) the updated list of dependencies, including what versions of which shared libraries you need installed, (b) pristine sources (see above), and (c) the RPM scripts that automatically shutdown/close/halt all necessary components, do the upgrade, then restart/open/run the program again. What happens if you do a "./configure ; make ; make install" on a server where you have a running Apache or Zope install? -> > A way to CLEANLY uninstall something. -> -> As said before: rm -r does that for Zope. And it only depends on you having -> the correct version of Python. Admittedly, with Zope the RPM thing is less of an issue because it's self-contained in its own directory. However, almost all of the GNU packages will put stuff in /usr/bin/, /usr/local/bin/, /usr/X11R6/, /lib, or some combintation thereof. So, I use RPMs. Since I use RPMs for everything else, I want to use it for Zope, too. -> Making binary distributions of any kind is a huge pain in the ass. Can you back this up? Many projects (MySQL? KDE?) just maintain the .spec file and auto-generate the RPMs for many different architectures. -> operating systems and version do you think Zope should have packages for? Just because we can't do ALL archictectures doesn't mean we shouldn't do at least a couple. -> How many would that amount to? How about the top 3? MS-Windows (already being done), i386 RPM (already being done but not auto-generated), and i386 DEB. Hell, if a SRPM were available, it would allow me to generate my own RPMs with a single --rebuild command. -> having a binary install. Instead somebody (and it seems to me that you guys -> think it is Zope corp ) has to maintain and test a ton of binary -> installations for several different version of several different operating -> systems. 1. I don't want Zope to test them. The community will do that. 2. An RPM .spec is very easy to maintain (or so I'm told) 3. I'm only asking for one, maybe two more than the Windows one they are already doing -> I suspect this is some of the reson for the great craving for RPM's. People -> simply do not realize that Zope installs much more easily and much more -> cleanly than most unix softwares. They don't realize that RPM's for Zope in -> most cases are more work than non-RPM installs. I want an RPM because, as someone who does use RPMs for system administration, I check to see if something is installed with a command like: [dereks@dereks src]$ rpm -qa | grep -i zope Zope-zserver-2.4.3-1 Zope-2.4.3-1 For me to (a) know, and (b) remember 6 months later, that Zope, unlike everything else on the system, was a tarball placed in /usr/share/zope or wherever, is an unsound administration practice. --Derek
From: "Derek Simkowiak" <dereks@realloc.net>
I.e., who knows whether or not that mirror you just downloaded from has a respectable admin...
1. If you download it from Zope org, theres no mirror involved. 2. What would prevent anybody from making an new install with new checksums? How come you trust a third-party RPM more than first party source? That just doesn't make sense.
I was referring to (a) the updated list of dependencies,
Python (yes, with threads and stuff).
including what versions of which shared libraries you need installed,
Which is exactly none.
(b) pristine sources (see above), and (c) the RPM scripts that automatically shutdown/close/halt all necessary components, do the upgrade, then restart/open/run the program again. What happens if you do a "./configure ; make ; make install" on a server where you have a running Apache or Zope install?
Nothing. Zope keeps running until you restart it.
-> Making binary distributions of any kind is a huge pain in the ass.
Can you back this up? Many projects (MySQL? KDE?) just maintain the .spec file and auto-generate the RPMs for many different architectures.
If you don't test the RPMs on the platforms you are supposed to support, then most of the benefits goes out the window, since the new RPM might end up not being useable, and then you have to install the source anyway...
1. I don't want Zope to test them. The community will do that.
Firstly, the community (ie *you*) can create them too. And secondly, if there are no RPM's created already, thats probably because it hasn't been a huge need for them in the community. If nobody wants to *do* RPM's, why do you think people want to *test* them?
3. I'm only asking for one, maybe two more than the Windows one they are already doing
Well, I'm not sure which are the biggest formats, but I do know that there are a lot of different unix version out there, and that they can't all use the same packages. You want RPMs for Red Hat Linux? What about packages for FreeBSD and OpenBSD 2.8, 2.9 and 3.0? There is a reason most unix software is distributed as source: Maintinning tons of different binary distributions is a pain in the royal ass.
On Fri, 2002-03-08 at 16:31, Derek Simkowiak wrote:
-> > RPM is system-wide version control. 'Pristine' sources. -> -> How can it be more pristine that getting the source from the manufacturer -> and compiling it?
It can be more pristine by having checksum, filesize, and public key signature checks to verify that you're using the source EXACTLY as distributed by the 'manufacturer'. I.e., who knows whether or not that mirror you just downloaded from has a respectable admin...
Of course, this doesn't do a dmaned thing if rpm has a script in it that does an rm -rf /var/lib/rpm.
RPM does this automatically for me, instead of me having to do it myself manually.
Uhh hold on their partner, rpm only checks sigs if you tell it to, it is an additional step. besides, I can provide source to a package, a checksum, and there you go.
-> > A safe upgrade path. -> -> How does this become more safe with RPM's? If a new version is incompatible -> with your data somehow, it will be incompatible no matter how many RPMs you -> throw at it.
I was not referring to data compatibility. What you say above is obvious.
Then, you meant convenient, not safe. ;^)
I was referring to (a) the updated list of dependencies, including what versions of which shared libraries you need installed, (b) pristine sources (see above), and (c) the RPM scripts that automatically shutdown/close/halt all necessary components, do the upgrade, then restart/open/run the program again. What happens if you do a "./configure ; make ; make install" on a server where you have a running Apache or Zope install?
The same thing as with an rpm. A Makefile can stop/start services and process just like an RPM does, and you *will* need a script to do so in either case.
-> > A way to CLEANLY uninstall something. -> -> As said before: rm -r does that for Zope. And it only depends on you having -> the correct version of Python.
Admittedly, with Zope the RPM thing is less of an issue because it's self-contained in its own directory. However, almost all of the GNU packages will put stuff in /usr/bin/, /usr/local/bin/, /usr/X11R6/, /lib, or some combintation thereof. So, I use RPMs. Since I use RPMs for everything else, I want to use it for Zope, too.
Well, you know what they say, if all you have is a hammer, everything looks like a nail. ;^)
Hell, if a SRPM were available, it would allow me to generate my own RPMs with a single --rebuild command.
You don't nee done of those, either. Just a spec file in a tarball. rpm -tb foo.src.rpm.
-> having a binary install. Instead somebody (and it seems to me that you guys -> think it is Zope corp ) has to maintain and test a ton of binary -> installations for several different version of several different operating -> systems.
1. I don't want Zope to test them. The community will do that. 2. An RPM .spec is very easy to maintain (or so I'm told) 3. I'm only asking for one, maybe two more than the Windows one they are already doing
Which would be followed later by this from someone else: "Hey, how come you provide an rpm for foo, but not bar. I want one for bar, and dammit, I like zope so you ZopeCo people need to get on the ball and make them. Don't worry, we the community can test them."
-> I suspect this is some of the reson for the great craving for RPM's. People -> simply do not realize that Zope installs much more easily and much more -> cleanly than most unix softwares. They don't realize that RPM's for Zope in -> most cases are more work than non-RPM installs.
I want an RPM because, as someone who does use RPMs for system administration, I check to see if something is installed with a command like:
[dereks@dereks src]$ rpm -qa | grep -i zope Zope-zserver-2.4.3-1 Zope-2.4.3-1
For me to (a) know, and (b) remember 6 months later, that Zope, unlike everything else on the system, was a tarball placed in /usr/share/zope or wherever, is an unsound administration practice.
To me, using a hammer on everything, even if it isn't a nail, is folly. :^) -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).
On Fri, 2002-03-08 at 12:15, Oleg Broytmann wrote:
On Fri, Mar 08, 2002 at 06:53:01PM +0100, Lennart Regebro wrote:
From: "Ron Arts" <raarts@netland.nl>
Most people want to install a binary package these days (in practice this means RPM).
Is this really true?
Yes.
Let's honest. One induces confusion by saying that there are no binary packages of Zope for Linux. If someone *means* RPMs then they damned well better say RPMS. While I have gone to the lengths of making RPMs for a simple two or three file install, Zope is something I, as an avid user of RedHat, sysadmin to dozens of machines over multiple sites, and fan of RPM, do not want Zope RPMs. I tried them. They sucked. *every* person I have introduced to zope, prefers the source to RPMs. RPMs have one glaring problem. To be safe, you *must* either download and rebuild a .src.rpm, or download both. Why? you may ask? Simple. You can get a list of the file sin an RPM, sure. But you don't get to see what scripts the rpm will execute when installing, without looking at the spec file. Period. I've seen more and more abuses of scripts in RPM.
From companie/people *assuming* that nobody ever installs rpms while in X and launching w/o question or option an program they explicitly say don't run in X (Since it is a guaranteed X-hanger), to things like mailing emails with system info out.
Anyway, didn't mean to get out on a rant there. The point is, the "desire" for RPMs of everything is not as prevalent as some people make it out to be. Of course, there is also the issue of Joe User who doesn't admin the machine wanting to install it locally; he can't use an rpm. he either downloads the source, or the binary package (which happens to include Python, IIRC).
When I install things on unix, I usually download and unzip a tgz file, run ./configure, write "make" and "make install", and I'm done.
That because you manage only one computer. Think about poor sysadmins who maintain dozens servers on a site - they just don't have enough time to untar and compile all that crap...
Which is why I create a nice little shar file that does those steps for me. Between that and ssh, is is no more difficult, and in many cases less difficult, than RPMs. -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).
Bill Anderson wrote:
RPMs have one glaring problem. To be safe, you *must* either download and rebuild a .src.rpm, or download both. Why? you may ask? Simple. You can get a list of the file sin an RPM, sure. But you don't get to see what scripts the rpm will execute when installing, without looking at the spec file. Period.
rpm -qp --scripts just-downloaded-rpm-file.rpm will do Bye -- Luca Olivetti
On Sat, 2002-03-09 at 04:32, Luca Olivetti wrote:
Bill Anderson wrote:
RPMs have one glaring problem. To be safe, you *must* either download and rebuild a .src.rpm, or download both. Why? you may ask? Simple. You can get a list of the file sin an RPM, sure. But you don't get to see what scripts the rpm will execute when installing, without looking at the spec file. Period.
rpm -qp --scripts just-downloaded-rpm-file.rpm
Only the ones listed in the spec-file, If I put mynastyscript.sh in the /tmp directory, and then run it in the postinstall, and the script removes itself, you have learned essentially nothing. Sorry, I was a bit terse in the original post. RPMs do little-to-nothing for security, convenience, yes, but not security. By the time you have looked at the scripts list, the files list, and verified the signature, you have fairly well eliminated a lot of the convenience. -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).
On Fri, 8 Mar 2002, Oleg Broytmann wrote:
That because you manage only one computer. Think about poor sysadmins who maintain dozens servers on a site - they just don't have enough time to untar and compile all that crap...
If they don't have time to maintain all of that why would they have time to download those RPMS all of the time. I think you are covering the precise reason for why I use debian on my workstations and servers. The latest zope is in unstable within about 3 days usually of a new release and a security fix within a day. That way you can upgrade it very easily across many machines. There is even a network shell that allows you to give one command to many machines at the same time. So if you want to install python imaging to lots of computers for a new product you can easily. I used to use redhat, mandrake, slackware etc for one machine for a few but the maintenance was just taking too long. Debian with apt-get or BSD with ports are a much better idea with many machines.
Ron Arts wrote: [snip]
1. Difficult installation.
Most people want to install a binary package these days (in practice this means RPM). When you look at the downloads, you see that the latest RPM is not the most recent Zope version. Oops! I thought, is this a serious product? (Please note: this first impression is important)
Another thing: how to install? PCGI? ZServer? There is no recommended way. Documentation is sparse on this matter.
The windows install is good, but you're missing most of the opensource community if the unix/linux people don't install zope. And many people *only* install rpm (if only for easy removal).
I have a completely different opinion on that matter. Making rpms is a real hell for software which depends anything else, at least as far as I can see in opensource land. OSS projects delivering _no_ rpms (other than from third parties) include: linux kernel, php, kde, apache httpd, perl, python ... In fact I don't know any project which takes the maintainance burden and even tries to deliver rpms, and nearly all of the above state the same reasons I do for not providing rpms. Zope-x.y.z-src's difference to nearly all of them is that it doesn't touch any files/directorys outside the directory you unpack it in. So removing zope from a system is as easy as rm -rf yourzopepath/ . Zope is included in all major distributions, it just has the problem, which is hopefully temporary, that it's dependencies on python-x.y.z change too fast. From an outside view, it seems that the development process of python itself is responsible for that. I really don't think that people not being able to comprehend tar xvfz zope-2.n.n-src.tar.gz python wo_pcgi.py start will have much fun with zope, anyway. And I strongly doubt these people are the unix/linux users of the "opensource community".
2. Unclear direction.
When I started browsing www.zope.org and all the dopcumentation, I came about three confusing differences: DTML, ZAL, and Zope3. It all was unclear to me, and if I will build a site in Zope I don't want to be on a dead trail. It is unclear to me which route I should take.
You are right, OTOH there were some statements here on some lists which did cover some topics of compatiblity of zope3 etc. Also, using google http://www.google.com/search?sourceid=navclient&q=%22zope+3%22+dtml+%22zope+... yields the following link at the third place: http://lists.zope.org/pipermail/zope-dev/2001-December/014313.html
3. downloadable product list.
Many products I downloaded did not work with my zope 2.5.0. ZopeGUD is broken. I could not even create an RPM for ZMySQLDA, even though I asked around on this list. So I still don't have MySQL access. Other products are listed as unmaintained. Why are they still on the list? Also there are duplicate products. The difference between them is not outlined, and nothing is recommended. Are some products far superior to others even though they seem to accomplish the same thing? I am forced to find out myself.
Yes, you are. Without adding the usual "unless you pay for it, that's open source" flamefest-attractor, I think it might be worth considering some technical helpers to mitigate some of these problems. Perhaps making products discussable on zope.org. Or adding some sort of a "compability feedback form", which automatically lists all existing zope versions (and OS variations, this is another problem) and people could post if it [works,doesn't work,needs small modifications to work}. These feedbacks should be counted, naturally, because individuals might make other mistakes etc. cheers, oliver
Most people want to install a binary package these days (in practice this means RPM). When you look at the downloads, you see that the latest RPM is not the most recent Zope version. Oops! I thought, is this a serious product? (Please note: this first impression is important)
I totally agree on this. That was my first impression - it could be cool, but I have to be a guru to install it. And that the RPMs are so out of date. There's no reason for this - if the spec file is maintained, you could automatically generate an rpm every time you tar up the release. A good spec file will also take care of dependencies, and defaults like pcgi or whatever, and also do nice stuff like put a startup script in init.d or whatever.
The good news: In the spirit of scratching your own itch, I have built an RPM set for Zope 2.5.0 that "works on my machine" :-) I based the spec on the 2.4.3 spec, but I stick much closer to the default install than the previous RPMS, effectively wrapping up a wo_pcgi build and packaging that with a /var/zope instance home. The RPMS also take care of logging stuff, startup scripts etc for you. PCGI is not supported, but you should be proxying to multi-threaded zserver using squid or apache if you're running Zope on linux anyway, (i.e. who cares). The spec should no longer be such a P.I.T.A. to update to the next Zope version, 'cause the RPM build simply executes a wo_pcgi build for you instead of individually compiling all the C extensions. The rpms require python 2.1.2 The bad news: The install sticks much closer to the default install than previously, effectively undoing a lot of the good restructuring work done in earlier RPM releases. The "throw everything in either /usr/share/zope or /var/zope" install is definitely not pretty (or FHS compliant). There is no "make install" equivalent functionality that puts stuff where it should be, IMHO this should be done by wo_pcgi, or distutils anyway, not by a monster 1000+ line spec. The extra files that used to be included, and the extra packages that used to get built, are gone. It's just the bare essentials. You get a Zope and Zope-zserver package, with only one doc included, the readme, (which is out of date) The rpms have only been tested on RedHat 7.2. After install, rpm -V will complain about a missing inituser file (zope deletes it after loading the user into the ZODB) One more thing, I'm not using these RPMS in production yet, and you probably shouldn't be either ;-) So here's the deal: If, after reading the above, anyone wants the source RPM, wants to work on it, make the w_pcgi build work with RPM, clean it up, host it, or install it (if you wanna be a tester), I'd be happy to email / upload to you the ~2Mb .src.rpm file. I can also tar up the spec and other files w/out the src tarball included for those who cannot receive a ~2Mb attachment. Adam
Adam Manock writes:
In the spirit of scratching your own itch, I have built an RPM set for Zope 2.5.0 that "works on my machine" :-) Congratulations and thank!
However, we know that Zope 2.5.0 contains a serious bug that may lead to memory corruption and nasty crashes. A 2.5.1 RPM would probably be more helpful. Dieter
Chris Withers writes:
Dieter Maurer wrote:
However, we know that Zope 2.5.0 contains a serious bug that may lead to memory corruption and nasty crashes. A 2.5.1 RPM would probably be more helpful.
We do? What is that? From the 2.5.1b1 announcement:
Fixed a crashing bug which resulted in the necessity of setting the workaround environment variable ZOPE_SECURITY_POLICY=PYTHON Dieter
At 06:59 AM 3/9/02, Dieter Maurer wrote:
Adam Manock writes:
In the spirit of scratching your own itch, I have built an RPM set for Zope 2.5.0 that "works on my machine" :-) Congratulations and thank!
However, we know that Zope 2.5.0 contains a serious bug that may lead to memory corruption and nasty crashes. A 2.5.1 RPM would probably be more helpful.
I built these RPMS to be simple and maintainable, it shouldn't take me long to package up 2.5.1 when it gets out of beta. Personally, I wasn't planning to deploy 2.5.0 in production, I'm planning on waiting and rolling out 2.5.1 instead. I built 2.5.0 RPMS strictly to aid in deployment of Zope to test / dev boxes. If anyone really needs a source rpm of 2.5.1b1 I'd be happy to build it for them, all you gotta do is ask :-) Another kind community member is going to cast a second set of eyes over the 2.5.0 RPM, as I don't exactly trust any package that hasn't been QA'd by at least two people, even if I did build it myself ;-) Eventually I'd like to see Zope Corp throw a the necessary scripts, readme and spec into the Zope source tree so that a CVS checkout of a tarball followed by a rpmbuild -ta TARBALL is all you would need to do to build new Zope rpms. Zope Corp doesn't need to maintain the stuff, although that would be nice. If the community maintainer(s) were informed of changes affecting the RPM build, like the access --> inituser change, and were in the loop about release target dates, etc, they could have rpms built in time for the release. Adam
Yes, once someone feels they have the right recipe, we can add it to our default build process. I propose that we take this item to the next step by peeling it out of this thread, taking it over to the dormant zope-packagers list, and ironing out the details: http://lists.zope.org/mailman/listinfo/zope-packagers I'll also note that Matt Behrens has signed up for a proposal that revisits the installation process, to be looked at for Zope 2.6. --Paul Adam Manock wrote:
At 06:59 AM 3/9/02, Dieter Maurer wrote:
Adam Manock writes:
In the spirit of scratching your own itch, I have built an RPM set for Zope 2.5.0 that "works on my machine" :-) Congratulations and thank!
However, we know that Zope 2.5.0 contains a serious bug that may lead to memory corruption and nasty crashes. A 2.5.1 RPM would probably be more helpful.
I built these RPMS to be simple and maintainable, it shouldn't take me long to package up 2.5.1 when it gets out of beta. Personally, I wasn't planning to deploy 2.5.0 in production, I'm planning on waiting and rolling out 2.5.1 instead. I built 2.5.0 RPMS strictly to aid in deployment of Zope to test / dev boxes. If anyone really needs a source rpm of 2.5.1b1 I'd be happy to build it for them, all you gotta do is ask :-)
Another kind community member is going to cast a second set of eyes over the 2.5.0 RPM, as I don't exactly trust any package that hasn't been QA'd by at least two people, even if I did build it myself ;-)
Eventually I'd like to see Zope Corp throw a the necessary scripts, readme and spec into the Zope source tree so that a CVS checkout of a tarball followed by a rpmbuild -ta TARBALL is all you would need to do to build new Zope rpms. Zope Corp doesn't need to maintain the stuff, although that would be nice. If the community maintainer(s) were informed of changes affecting the RPM build, like the access --> inituser change, and were in the loop about release target dates, etc, they could have rpms built in time for the release.
Adam
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Initial requirements for a Zope RPM need to be nailed down. So far, IMHO: Zope >= 2.5.0 requires python2.1 >= 2.1.2 enforced by RPM (reduce zope@zope.org list traffic :-) Minimum of Zope data area broken out of main directory heirachy to a /var/zope INSTANCE_HOME. standard chkconfig stuff, zope user creation, etc. Undecided: PCGI? Put zope-PCGI in a separate spec / source package? An additional (optional to build and install) package? Narrowing the scope to only support zope w/zserver in the main package initially = earlier initial release. Ron, does your 2.5.0 package already take care of cleanly building PCGI?? Adam PS <thread should continue on Zope-Packagers list, this being the first and last cross post :-)> At 07:04 AM 3/13/02, Paul Everitt wrote:
Yes, once someone feels they have the right recipe, we can add it to our default build process.
I propose that we take this item to the next step by peeling it out of this thread, taking it over to the dormant zope-packagers list, and ironing out the details:
http://lists.zope.org/mailman/listinfo/zope-packagers
I'll also note that Matt Behrens has signed up for a proposal that revisits the installation process, to be looked at for Zope 2.6.
--Paul
Adam Manock wrote:
At 06:59 AM 3/9/02, Dieter Maurer wrote:
Adam Manock writes:
In the spirit of scratching your own itch, I have built an RPM set for Zope 2.5.0 that "works on my machine" :-) Congratulations and thank!
However, we know that Zope 2.5.0 contains a serious bug that may lead to memory corruption and nasty crashes. A 2.5.1 RPM would probably be more helpful.
I built these RPMS to be simple and maintainable, it shouldn't take me long to package up 2.5.1 when it gets out of beta. Personally, I wasn't planning to deploy 2.5.0 in production, I'm planning on waiting and rolling out 2.5.1 instead. I built 2.5.0 RPMS strictly to aid in deployment of Zope to test / dev boxes. If anyone really needs a source rpm of 2.5.1b1 I'd be happy to build it for them, all you gotta do is ask :-) Another kind community member is going to cast a second set of eyes over the 2.5.0 RPM, as I don't exactly trust any package that hasn't been QA'd by at least two people, even if I did build it myself ;-) Eventually I'd like to see Zope Corp throw a the necessary scripts, readme and spec into the Zope source tree so that a CVS checkout of a tarball followed by a rpmbuild -ta TARBALL is all you would need to do to build new Zope rpms. Zope Corp doesn't need to maintain the stuff, although that would be nice. If the community maintainer(s) were informed of changes affecting the RPM build, like the access --> inituser change, and were in the loop about release target dates, etc, they could have rpms built in time for the release. Adam _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
marc lindahl writes:
Most people want to install a binary package these days (in practice this means RPM). When you look at the downloads, you see that the latest RPM is not the most recent Zope version. Oops! I thought, is this a serious product? (Please note: this first impression is important)
I totally agree on this. That was my first impression - it could be cool, but I have to be a guru to install it. And that the RPMs are so out of date.
There's no reason for this - if the spec file is maintained, you could automatically generate an rpm every time you tar up the release. A good spec file will also take care of dependencies, and defaults like pcgi or whatever, and also do nice stuff like put a startup script in init.d or whatever. Do I hear a volunteer here?
Dieter
On Fri, 8 Mar 2002, Oliver Bleutgen wrote: Regarding the thread about the "stalled" community and documentation issues in general, what can we, as a community, do? I'm a community organizer by history, so I think this is a worthwhile question to ask. I think it would help to re-cap what we've said and to list what the possibility that have been raised are. Some good suggestions that were raised: * some people prefer RPMS (& they're not neccessarily bad people) I'm comfy with unpacking and making, but my I'm a Unix weenie. Some people aren't. Some are and prefer RPMS (I do for _many_ things, for instance). Some people (for good security reasons) don't have gcc/make on their webservers, and find it difficult to make-elsewhere-then-move. So, can we make RPMS for Zope? True, some OSS project don't provide RPMS; some (MySQL, PostgreSQL) do, and on these projects, we recognize that people who want to play around, test something out, etc., will install and RPM and play, whereas if they felt that had to do a "hard install", they wouldn't. * there's lots of knowledge on the ML and lots in the HOWTOs, but it takes a while to search Can someone (or a team) step forward and be willing to play librarian with the HOWTOs, perhaps categorizing them better, dividing them into definitely-outdated-no-longer-important versus diamond-in-the-rough. Can they have more keywords and a better search engine? * Products are half-finished or don't work with all versions Can someone extend the Products Product so that Products can be commented on, rated, and listed as working with certain versions of Zope? Does anyone want to work on the batteries-included distro of Zope that would include popular but non-core things like exUserFolder, CMF, TransparentFolders, etc.? * ZDP seems dead in the water Yep it does. Does somebody want to start the conversation about what role user-contributed docs will play? How will this be different than the HOWTOs at zope.org? * We lack some reward systems Someone pointed out in the thread that if you design projects, they can help you with consulting and your resume, more than the "good feeling" that comes from writing docs or coordinating systems. This may be true for many of us (I have to work to eat, for instance). So: what reward systems can we think of that will reward those who do the organizing and documentation-writing? Does ZC have some t-shirts to kick forth? A Zope Community prize to Best Contributors? Prominent, rotating mention on the zope.org site? If you haven't helped out and can give voice to what might motivate you, please say so. It will help. * We (sometimes) lack coordination Does somebody want to step forward as a coordinator-of-coordinators, keeping a list like this of non-programming projects that need help, so that when we have some time, we know where to apply our talents? So, so far, we have the following volunteer positions open: * RPM maintainer * HOWTO categorizers/maintainers * HOWTO product improvements * Product improvements * Product library maintainers * ZDP team * Volunteer coordinator I'm interested in working on the HOWTOs: helping categorize, modernize, etc. Anyone want to join me? Anyone want to do anything else? -- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant
This has been a very interesting thread, with many good points. Thanks to all who have posted. There were a couple of points I thought were complete rubbish. Like the idea that Zope is "more complex" than PHP, and thus can't be as well-documented. I'm sorry, but "functions" are no more easy to document than "object hierarchies". (OOP theory would state quite the opposite, in fact.) Compare Zope and MySQL. Both have the same business model, both are popular OSS products, and both have similar target markets/communities. Yet the MySQL documentation (both the User Manual and the developer's docs) are far more extensive than Zope's. PHP, GTK+, Qt, Apache, the Linux Operating System, SGI's OpenGL, SDL, the Python programming language, and the Perl programming language all have documentation that far surpasses that of Zope. Even smaller one-man projects like PyUI, or Pango, do a better job than Zope.org. It would be great if we understood why. Could it be that Zope community is just 'different'? Maybe, but I doubt it, because the Zope community overlaps with the PHP, MySQL, and Apache communities quite heavily. With the exception of the Linux Documentation Project (which has an almost unlimited scope, everything from Linux Quake install to RAID), docs are not written by the community. Having watched and participated in a few OSS projects, I've observed that almost all OSS documents are written by the people doing the coding. The PHP functions were documented by the guys who wrote those PHP functions. Note that a name on most of the Python docs is "Guido Van Russum" (who ironically enough works for Zope Corp). Most of the Apache docs were written by the core Apache developers. All of the Pango docs were written by Owen Taylor. Could it be Zope Corp's lack of prioritization? Maybe Zope Corp. management believes that "if you're busy writing docs, you're not busy developing", and so has set a mandate. Or more likely, Zope Corp just has a developer-centric company culture, and we all know how much developers like to write docs (right, Andreas? :). My personal opinion is that Zope Corp needs to realize that the community is faltering due to lack of docs, and re-prioritize. No, writing docs won't bring in cash directly. No, developers are not happy retrofitting docs for production-level code. But as somebody who stuck my neck out for Zope, and is now realizing how hard it is to find up-to-date info, I think this is a fair thing to ask of Zope Corp. Sitting on my desk right now are _The Zope Book_, _Zope Web Application Development and Content Management_, and _Zope web application construction kit_. They are mostly very good stuff, and given the present situation on Zope.org, I recommend them to anyone interested in Zope. Unfortunately, books can't keep up with issues (like Office XP and WebDAV), and the HowTos (or even mini-HowTos) just aren't getting written. Thank You, Derek Simkowiak
Derek Simkowiak wrote:
Compare Zope and MySQL. Both have the same business model, both are popular OSS products, and both have similar target markets/communities. Yet the MySQL documentation (both the User Manual and the developer's docs) are far more extensive than Zope's. PHP, GTK+, Qt, Apache, the Linux Operating System, SGI's OpenGL, SDL, the Python programming language, and the Perl programming language all have documentation that far surpasses that of Zope. Even smaller one-man projects like PyUI, or Pango, do a better job than Zope.org.
Regarding Zope's documenation: The "core" Zope documentation is actually in pretty good shape, these days. The problem is, a whole lot of Zope isn't "how do I do X" where "X" is some simple functional/procedural thing. Instead, its more of a problem of "whats the best way to do X" or "why do X vs Y?" It's lore, not API. There is an enormous amount of the Zope code base that is there because it evolved that way. A lot of it becomes very optional from the API layer, so pure API documentation becomes misleading -- it does not address deeper questions of "why does it work THIS way?" This is the biggest hurdle in Zope, in my opinion; the fact that one developer did things one way sort of "blazes a trail" but that trail may be neither intuitive, nor obvious, to another observer. I can affirmatively state there are things that routinely exasperate me, because I want to make a little tweak to an existing example -- but I can't do it with a little tweak. Instead, I end up subclassing and patching and coding all around, and that carries a high inertia, impeding my progress. True, I can blame some of this on my fellow developers (and myself, too!) if I had the "this is WHY I the code is written like this" narrative document, I could usually pick up the how as a consequence of the why. Instead, one is often left to study the plumbing to figure out theories of hydrodynamics. I find that my biggest enemy in Zope is the innocuous text field. In one of those many text fields in the management interface, you can type "anything." Chances are good though, that only a few things will work. It is frustrating when you're exposed to a "place to put something" when you dont know what *really* goes there, besides perhaps some simplitic truism from the Help System (put the foobar in the foobar slot). Thus, I find the core of Zope to be very elegant and pleasing, but I find some of the contortions that need to take place to use OTHER people's notions on how Things Are To Be Done to be awkward and obtuse at times. In many cases, one can go look at what those additional products do for documentation, and find that only the surface has been skimmed; essentially the 5% level -- you're left with no progression to navigate the remaining 95%. I'm not going to name names, but I know a lot of my frustrations aren't unique. Some of these frustrations aren't purely Zope, either. I remember getting *very* angry at javadoc back in 1996 because I could find documentation on the "middle pieces" but no end pieces; I didn't want to replumb the graphics pipeline, I just wanted to do a few simple things, and no where was the arrow saying "THIS IS WHAT YOU WANT." The corollary to this is that good programmers are trained via an apprenticeship -- it is vastly easier to gather knowledge by observing the wise than it is by starting with the Experimental Method and going from there. -- Matt Kromer Zope Corporation http://www.zope.com/
Derek Simkowiak writes:
... My personal opinion is that Zope Corp needs to realize that the community is faltering due to lack of docs, and re-prioritize. No, writing docs won't bring in cash directly. No, developers are not happy retrofitting docs for production-level code. But as somebody who stuck my neck out for Zope, and is now realizing how hard it is to find up-to-date info, I think this is a fair thing to ask of Zope Corp. A strange view...
When Zope Corp would realize that its work falters, this would call for re-prioritization. When the community (or part thereof) realizes it needs more documentation, then it can start to provide them. You got Zope, a nice piece of software. What did you give that you think it is fair to ask for more? I think, Zope Corp has the same right than you have to focus on their customer projects and only then look for the community...
.... Unfortunately, books can't keep up with issues (like Office XP and WebDAV), and the HowTos (or even mini-HowTos) just aren't getting written. Then start to write some of them! You are part of the community...
Dieter
-> You got Zope, a nice piece of software. What did you give -> that you think it is fair to ask for more? Well, let's see. 1. I installed, ran, and tested it on two new pieces of hardware. 2. I reported a (minor) bug in the MySQLDA and provided a fix. 3. I proposed Zope to my boss as a solution for one of our clients. If the client accepts the proposal, we'll probably be using Zope Corp as a subcontractor ($$$). 4. I take the time to write my opinions and needs to the Zope mailing list, i.e., I act as a "customer" telling Zope Corp what I want from future versions of Zope (like more docs, updated RPMs, etc.) Many companies have to pay big $$$ to do market research. 5. I've answered at least a couple of (easy) Zope questions on the mailing list. 6. I care about Zope being a Quality product. I do not consider myself to be an actual "contributor" to Zope; on the contrary, my involvement is very ancillary. But the above are minor examples of very major services the community provides to Zope Corp. I wasn't trying to say the Zope is "obligated" to do anything at all. I was trying to say that, in order to be more successful, Zope needs better docs -- that's why it's fair to ask that of them, because they have more control than anyone over what Zope docs wind up getting written. -> I think, Zope Corp has the same right than you have to focus -> on their customer projects and only then look for the community... Agreed. But, as far as I can tell, the needs of "the community", and the needs their "customers", are basically the same thing. Is that not what their OSS business model is based upon? -> Then start to write some of them [HowTos]! You are part of the -> community... I would, and I have in the past for other projects, but I don't know enough about Zope yet to really contribute. Hmm, maybe if there were more docs for me to read so I could get up to speed... hehe :) --Derek
Ok, my take on comparing Zope with other OSS projects.. If you look back in time, to the beginning of MySQL, PHP and Apache, what made those products so succesfull? MySQL started from a company (like Zope Corp), PHP from an individual (Rasmus Lehrdorf) and Apache from a bunch of unix sysadmins. All these products: - filled a real *need* - had little competition - were well-documented with *lots* of examples to get you started. - and the programmers listened to their users *and* sysadmins. PHP: there was no general purpose serverside scripting language, also it looked a lot like 'C' and so appealed to the unix crowd out there. MySQL: the need for a fast database to be used from PHP. The only competitors at that time were mSQL (crippled) and Postgres95 (slow and buggy). Apache: because NCSA was hardly maintained any more, apache was basically the only one in the market, and it was good! At that time RPM was not there and many other OSS programs did not use "./configure; make; make install". But these did. Those days this was sensible advanced system management, so it appealed to admins. Also there was documentation with lots of examples, so it appealed to programmers. Because of the needs, functionality and easy learning curve these projects picked up a lot of steam quickly. This generated a large community, lots of feedback, and because the builders kept listening and keeping up these projects became the best in the OSS world. Enter Zope. Zope really has potential to become one of the best website platforms in OSS world, and I am very enthusiastic about it. It has little competition and fills a real need. My personal opinion is that Zope is not taking off as it should because of three things: - documentation without lots of examples. I know, there is the Zope Book, but take away the screen dumps, and look again. - not keeping up with good sysadmin practices (RPM) - not enough listening to users (sysadmins + programmers) I think Derek's remarks are pretty well on the spot. If Zope Corp wants Zope to take off just like MySQL AB did with MySQL here is my advice: work along the same principles: documentation (examples plus reference), easy installation, lay down a clear path, and listen to your users. The community can contribute (and they will), but the actual programmers need to be heavily involved. BTW: Don't think Zope does not do anything right, certainly not. The product itself looks very good, stable, very functional. New version announcements to freshmeat and other places are *very important*. Keep them coming. Ron Arts
I really don't think that people not being able to comprehend tar xvfz zope-2.n.n-src.tar.gz python wo_pcgi.py start
will have much fun with zope, anyway. And I strongly doubt these people are the unix/linux users of the "opensource community".
Dire open source snobbery. And **if only** it were so simple (http://www.zope.org/Members/mcdonc/HowTos/zopeinstall/ZOPE-INSTALL-HOWTO details 19 stages of the Zope installation actually) Oliver, were you honestly born knowing what these things meant? No, we all learn the language we need, at the time we need it. The question is, do you help people learn it, ignore them for being clueless, or insult their intelligence while looking down your nose at them? :-( D. -- Douglas Carnall tel:+44 (0)20 7241 1255 fax:08700 557879 mob:07900 212881 http://www.carnall.org/ dougie@carnall.org
On Sat, 2002-03-09 at 02:31, Douglas Carnall wrote:
I really don't think that people not being able to comprehend tar xvfz zope-2.n.n-src.tar.gz python wo_pcgi.py start
will have much fun with zope, anyway. And I strongly doubt these people are the unix/linux users of the "opensource community".
Dire open source snobbery. And **if only** it were so simple (http://www.zope.org/Members/mcdonc/HowTos/zopeinstall/ZOPE-INSTALL-HOWTO details 19 stages of the Zope installation actually)
Actually, no, it does not document 19 steps to installing, it documents steps to customizing/UPGRADING. Is there a difference? You betcha! Especially since most of those 19 are applicable *only* to those performing upgrades, and downloading Zope is listed as a step. Please be more thorough in the future. :^) On a Unix system: tar -xvzf zope-x.x.x.src.tgz cd zope-x.x.x python wo_pcgi.py Is a complete install. Now, *customizing* that install is a *separate* matter. if all you want to do, for example, is play around with it, the above procedure meets that need perfectly. Connecting Zope to a front-end webserver, is a customization. If you have Zope installed, you are not installing, you are upgrading. Furthermore, the referenced document is for "binary" installs. Note further that to install it, you untar it, then proceed to run the install script. One-step install (three if you want to count downloading and extracting), followed by local-site configuration and customization. -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).
On Fri, Mar 08, 2002 at 06:01:45PM +0100, Ron Arts wrote:
Basically what I miss is a clear path to take, many recommendations (PHP has lots of those) easy RPM installation, and a bag of working trustworthy Products (preferably distributed as RPM's).
I can at least talk a bit about the last couple of points. Debian has packages for at least the following Zope-related items (in the testing and unstable releases of Debian, at least): psycopgda, popyda, zwiki, zshell, zpatterns, znavigator, zieve, zcvsmixin, tinytable, renderable, parsedxml, mysqlda, loginmanager, ldap, eventfolder, emarket, developers guide, cmf, book, squishdot Though I can't say that every one is working and trustworthy, the ones I've used have been. They're not RPM's, but since I don't run Redhat boxes, that's not a drawback for me. The "stable" release of Debian lags quite a bit behind current Zope, largely due to its lack of Python 2.x. But the testing or unstable releases are probably of comparable quality to any released RPM-based distribution. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- renfro@tntech.edu
Ron Arts writes:
... 1. Difficult installation. ... The windows install is good, but you're missing most of the opensource community if the unix/linux people don't install zope. And many people *only* install rpm (if only for easy removal). Zope's (non RPM) installation lives in a single directory. Removal is as easy as with "rpm": "rm -r Zope".
... 3. downloadable product list.
Many products I downloaded did not work with my zope 2.5.0. ZopeGUD is broken. I could not even create an RPM for ZMySQLDA, even though I asked around on this list. So I still don't have MySQL access. Apparently, that's because you are fixed to RPM...
Other products are listed as unmaintained. Why are they still on the list? Probably, because they may nevertheless be useful...
Dieter
My 2 cents ( $Au) On Saturday 09 March 2002 04:01 am, you wrote:
Hi,
I am a newcomer in Zope (been using it for a week), coming from PHP. My view of Zope is still fresh. I am a very experienced Linux admin from the ISP world, but also a C programmer.
I think Zope has the following problems:
1. difficult installation (What? you say? I'll come to that)
Yes, rpms would be good, however, Zope is very customisable and has to co-exist with python (it took me days to get Zope to use MySQL, in the end, it was as easy as installing from source instaed of using a binary install). I don't believe there is anything wrong (or difficult) with installing from source.
2. unclear direction
Yes, I agree, this would also alleviate problem 1.
3. downloadable productlist 'unreliable'
I have had problems with products not working with my installs as well - however: The products SHOULD mention which Zope version they were written for.
4. small but showstopping documentation deficiences
Don't know about "showstopping" but sometimes it feels like banging my head against a brick wall might help more than the documentation - HOWEVER, this last year it's been great to see books appear everywhere, it's just a pity that we have great stuff like ZPT and CMF evolving and, lo and behold, causing documentation deficiencies (wonder what Zope 3 will do to the documentation and examples?). Should we be denied access to these things until the documentation is up to scratch? Regards, Mehmet
participants (22)
-
Adam Manock -
Bill Anderson -
BZ -
Chris McDonough -
Chris Withers -
Christian Theune -
Derek Simkowiak -
Dieter Maurer -
Douglas Carnall -
Joel Burton -
kosh＠aesaeion.com -
Lennart Regebro -
Luca Olivetti -
marc lindahl -
Matthew T. Kromer -
Mehmet Yousouf -
Mike Renfro -
Oleg Broytmann -
Oliver Bleutgen -
Paul Everitt -
Ron Arts -
Stefan H. Holek