I'm new to Zope, and I've been playing with 2.8.1, but I really haven't done any real work with it yet. Now I expect to get my new decicated Zope hardware tomorrow, so I have to decide if I should go for 2.8.4 or 3.1.0. Any tips if I should go for the latest and greatest or stick with 2.8? I've also seen comments that running Zope on RHEL/CentOS might not be wise. My test env. is using FC4, but I'm planning to install CenOS 4.2 on the production server. Unwise choice? Regards, Harald
We use lots and lots of Centos 4.x servers not a problem there go for it. Andrew Sawyers Zope Corporation Zope Managed Hosting Software Engineer _____ From: zope-bounces@zope.org [mailto:zope-bounces@zope.org] On Behalf Of Harald Finnås Sent: Wednesday, October 26, 2005 4:43 PM To: zope@zope.org Subject: [Zope] Zope 2.8 or 3.1? I'm new to Zope, and I've been playing with 2.8.1, but I really haven't done any real work with it yet. Now I expect to get my new decicated Zope hardware tomorrow, so I have to decide if I should go for 2.8.4 or 3.1.0. Any tips if I should go for the latest and greatest or stick with 2.8? I've also seen comments that running Zope on RHEL/CentOS might not be wise. My test env. is using FC4, but I'm planning to install CenOS 4.2 on the production server. Unwise choice? Regards, Harald
On Wed, 26 Oct 2005 13:43:21 -0700, HaraldFinnås <spamcatcher@lantrix.no> wrote:
I'm new to Zope, and I've been playing with 2.8.1, but I really haven't done any real work with it yet. Now I expect to get my new decicated Zope hardware tomorrow, so I have to decide if I should go for 2.8.4 or 3.1.0. Any tips if I should go for the latest and greatest or stick with 2.8?
These are two totally separate code bases, and have nothing at all to do with each other. Zope 3 is a ground-up rewrite of Zope, and shares no code (or application compatibility) with Zope 2. -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
On 26 Oct 2005, at 21:43, HaraldFinnås wrote:
I've also seen comments that running Zope on RHEL/CentOS might not be wise. My test env. is using FC4, but I'm planning to install CenOS 4.2 on the production server. Unwise choice?
I'd be curious to find out who says something like that. It's BS. Zope runs perfectly fine on all RHEL-based distributions. The only issues you might ever run into would be problems with the Python that comes with the OS. But then again if you run Zope in production you should never ever use the system Python and build your own instead. The system Python tends to be compiled with weird flags on RH-based distros to suit their own needs for the many Python-based scripts they have in the OS. Don't use it, build your own. jens
Jens Vagelpohl wrote:
On 26 Oct 2005, at 21:43, HaraldFinnås wrote:
I've also seen comments that running Zope on RHEL/CentOS might not be wise. My test env. is using FC4, but I'm planning to install CenOS 4.2 on the production server. Unwise choice?
I'd be curious to find out who says something like that. It's BS. Zope runs perfectly fine on all RHEL-based distributions.
The only issues you might ever run into would be problems with the Python that comes with the OS. But then again if you run Zope in production you should never ever use the system Python and build your own instead. The system Python tends to be compiled with weird flags on RH-based distros to suit their own needs for the many Python-based scripts they have in the OS. Don't use it, build your own.
well, on larger shops like ours, the sysadms always want to know why we introduce Yet Another Non-Standard Component to the system setup that cannot be RPM'ed like the rest. And I am not talking across pythoin versions, but oin the same release series (ie. 2.3, etc) I know it is more convenient to self.compile() the python, but it is always hard to argue with the sysadms on this issue. Our current solution is to provide a precomipiled rpm with the pythons we want to use. Why is that the standard os-distributed pythons do not work with zope? They seem to work with other python sw... /dario - being curious... -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
On 27 Oct 2005, at 08:58, Dario Lopez-Kästen wrote:
well, on larger shops like ours, the sysadms always want to know why we introduce Yet Another Non-Standard Component to the system setup that cannot be RPM'ed like the rest. And I am not talking across pythoin versions, but oin the same release series (ie. 2.3, etc)
I know it is more convenient to self.compile() the python, but it is always hard to argue with the sysadms on this issue. Our current solution is to provide a precomipiled rpm with the pythons we want to use.
Why is that the standard os-distributed pythons do not work with zope? They seem to work with other python sw...
For the Zope setups the pattern that I have seen most often in larger shops is buildout scripts that create self-contained full instances with Python, Zope and the instance home. These are easy to set up and update with one simple buildout script or Makefile or whatever strikes your fancy. This is exactly the same level of "convenience" (and maintainability) as saying "rpm -Uvh foo.rpm". Obviously this self-contained ZEO client with its own Python could be done as a RPM or set of RPMs as well. The main idea is that you isolate Zope and Python from the rest of the system. You can then use simple auto-upgrading schemes like yum or even the redhat network to keep everything up to date, while never running the risk of influencing or bringing down Zope by making unforeseen changes to the Python in use, as could happen with the system Python. The same is true for any add-ons you might install into the Python used for Zope. jens
On Thu, Oct 27, 2005, Jens Vagelpohl wrote:
On 27 Oct 2005, at 08:58, Dario Lopez-Kästen wrote:
well, on larger shops like ours, the sysadms always want to know why we introduce Yet Another Non-Standard Component to the system setup that cannot be RPM'ed like the rest. And I am not talking across pythoin versions, but oin the same release series (ie. 2.3, etc)
I know it is more convenient to self.compile() the python, but it is always hard to argue with the sysadms on this issue. Our current solution is to provide a precomipiled rpm with the pythons we want to use.
Why is that the standard os-distributed pythons do not work with zope? They seem to work with other python sw...
For the Zope setups the pattern that I have seen most often in larger shops is buildout scripts that create self-contained full instances with Python, Zope and the instance home. These are easy to set up and update with one simple buildout script or Makefile or whatever strikes your fancy. This is exactly the same level of "convenience" (and maintainability) as saying "rpm -Uvh foo.rpm". Obviously this self-contained ZEO client with its own Python could be done as a RPM or set of RPMs as well.
The main idea is that you isolate Zope and Python from the rest of the system. You can then use simple auto-upgrading schemes like yum or even the redhat network to keep everything up to date, while never running the risk of influencing or bringing down Zope by making unforeseen changes to the Python in use, as could happen with the system Python. The same is true for any add-ons you might install into the Python used for Zope.
We've been running Zope and Plone built under the OpenPKG.org portable packaging system for a couple of years now. The OpenPKG system avoids problems with vendor python and other packages. Bill -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ ``The best we can hope for concerning the people at large is that they be properly armed.'' -- Alexander Hamilton, The Federalist Papers at 184-188
Am Donnerstag, 27. Oktober 2005 09:37 schrieb Jens Vagelpohl:
The only issues you might ever run into would be problems with the Python that comes with the OS. But then again if you run Zope in production you should never ever use the system Python and build your own instead. The system Python tends to be compiled with weird flags on RH-based distros to suit their own needs for the many Python-based scripts they have in the OS. Don't use it, build your own.
I'd be very curious to hear about what real life problems people have observed. The advice is mention so often here, without any proof (at least thats my impression). Does it run slow? Does product xy behave strange? Does it crash? We have some well loaded (2.8.x ZEO setup) servers up and running, using the standard python install that comes with fedora 3 (or their official updates), and that seems not to have any obvious disadvantages (beside the fact, that they still offer 2.3.4 only). Cheers, Sascha -- Gallileus - the power of knowledge Gallileus GmbH http://www.gallileus.info/ Pintschstraße 16 fon +49-(0)30-41 93 43 43 10249 Berlin fax +49-(0)30-41 93 43 45 Germany
On 27 Oct 2005, at 10:22, Sascha Ottolski wrote:
Am Donnerstag, 27. Oktober 2005 09:37 schrieb Jens Vagelpohl:
The only issues you might ever run into would be problems with the Python that comes with the OS. But then again if you run Zope in production you should never ever use the system Python and build your own instead. The system Python tends to be compiled with weird flags on RH-based distros to suit their own needs for the many Python-based scripts they have in the OS. Don't use it, build your own.
I'd be very curious to hear about what real life problems people have observed. The advice is mention so often here, without any proof (at least thats my impression). Does it run slow? Does product xy behave strange? Does it crash?
We have some well loaded (2.8.x ZEO setup) servers up and running, using the standard python install that comes with fedora 3 (or their official updates), and that seems not to have any obvious disadvantages (beside the fact, that they still offer 2.3.4 only).
You just noted one more disadvantage yourself: The system Python is likely to be out of step with what Zope wants. Furthermore, updates to the system Python or to add-on packages might have unintended consequences for your Zope setup. jens
Am Donnerstag, 27. Oktober 2005 13:20 schrieb Jens Vagelpohl:
You just noted one more disadvantage yourself: The system Python is likely to be out of step with what Zope wants. Furthermore, updates to the system Python or to add-on packages might have unintended consequences for your Zope setup.
well, "might have" is one thing, really experiencing problems is quite different... -- Gallileus - the power of knowledge Gallileus GmbH http://www.gallileus.info/ Pintschstraße 16 fon +49-(0)30-41 93 43 43 10249 Berlin fax +49-(0)30-41 93 43 45 Germany
On 27 Oct 2005, at 12:55, Sascha Ottolski wrote:
Am Donnerstag, 27. Oktober 2005 13:20 schrieb Jens Vagelpohl:
You just noted one more disadvantage yourself: The system Python is likely to be out of step with what Zope wants. Furthermore, updates to the system Python or to add-on packages might have unintended consequences for your Zope setup.
well, "might have" is one thing, really experiencing problems is quite different...
Look, it's all about how much risk you are willing to carry. I don't like playing Russian Roulette with services that are supposed to be highly available. And I don't want to have to waste a single thought on problems that *might* develop if RedHat or their packagers decide to do something to their Python or to Python add-ons I use. I also prefer to do upgrades to these components on my own schedule, not when someone else who has no idea about my various usage scenarios thinks so. jens
Am Donnerstag, 27. Oktober 2005 14:17 schrieb Jens Vagelpohl:
well, "might have" is one thing, really experiencing problems is quite different...
Look, it's all about how much risk you are willing to carry. I don't like playing Russian Roulette with services that are supposed to be highly available. And I don't want to have to waste a single thought on problems that *might* develop if RedHat or their packagers decide to do something to their Python or to Python add-ons I use. I also prefer to do upgrades to these components on my own schedule, not when someone else who has no idea about my various usage scenarios thinks so.
hey, no offence, I absolutely see your point. it's just that I'm really curious about what practical problems people have seen, as we seem not to have any...and in my point of view, it's less to think about when I simply stick to the packages that come with the OS :-) cheers, Sascha -- Gallileus - the power of knowledge Gallileus GmbH http://www.gallileus.info/ Pintschstraße 16 fon +49-(0)30-41 93 43 43 10249 Berlin fax +49-(0)30-41 93 43 45 Germany
On 27 Oct 2005, at 13:30, Sascha Ottolski wrote:
Look, it's all about how much risk you are willing to carry. I don't like playing Russian Roulette with services that are supposed to be highly available. And I don't want to have to waste a single thought on problems that *might* develop if RedHat or their packagers decide to do something to their Python or to Python add-ons I use. I also prefer to do upgrades to these components on my own schedule, not when someone else who has no idea about my various usage scenarios thinks so.
hey, no offence, I absolutely see your point. it's just that I'm really curious about what practical problems people have seen, as we seem not to have any...and in my point of view, it's less to think about when I simply stick to the packages that come with the OS :-)
For me that's true with pretty much every single package - apart from Zope and the Python that runs it. I would never advocate any strategy that leans heavily on the "build myself" side. That's just insane maintenance. System packages should be used wherever possible (like Apache, etc). In cases where you have a better (or purpose-built) replacement for a system package then build a package that meshes with your system packaging and replaces the original. I've been building my own Squid and sometimes Postfix RPMs on many occasions. jens
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sascha Ottolski wrote:
Am Donnerstag, 27. Oktober 2005 13:20 schrieb Jens Vagelpohl:
You just noted one more disadvantage yourself: The system Python is likely to be out of step with what Zope wants. Furthermore, updates to the system Python or to add-on packages might have unintended consequences for your Zope setup.
well, "might have" is one thing, really experiencing problems is quite different...
It *has* happened to Real Zope Users (TM) in the past, and it *will* happen again. One "unintended consequence" of using /usr/bin/python on RHEL / Fedora boxen, for instance, is that they compile Python with UCS-4 unicode (four bytes for every unicode character!). This setting doesn't matter for short-lived scripts or GUI utils, and may even be superior. For a long-running, memory-intensive Python process, it is grossly nefficient. WRT maintenance of the system: while at ZC, I actually maintained a separate 'zc-python' RPM which installed itself in '/opt/zc'; all the Zope RPMs I maintained depended on 'zc-python' rather than 'python'. Users whose pagers / cell phones go off if Zope crashes (this is my definitino of "enterprise user", BTW) should install a separate Python. Non-enterprise users can likely get away without it. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYPch+gerLs4ltQ4RAjBwAKDJVAl/igH7hnSeYNRzceXyC8qvHgCgkKIK 5zjZgfdq6bCnOPMuGxPqozc= =E9Fl -----END PGP SIGNATURE-----
WRT maintenance of the system: while at ZC, I actually maintained a separate 'zc-python' RPM which installed itself in '/opt/zc'; all the Zope RPMs I maintained depended on 'zc-python' rather than 'python'.
What's the recommended way of maintaining an extra Python installation for Zope? Is changing the path enough or should one run the instance in a chroot'ed environment? And what's supposed to be the "correct" Python version for 2.8.4 btw? Regards, Harald
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HaraldFinnås wrote:
WRT maintenance of the system: while at ZC, I actually maintained a separate 'zc-python' RPM which installed itself in '/opt/zc'; all the Zope RPMs I maintained depended on 'zc-python' rather than 'python'.
What's the recommended way of maintaining an extra Python installation for Zope? Is changing the path enough or should one run the instance in a chroot'ed environment?
I never set Zope up in a chroot (not that that is necessarily wrong, it just didn't seem worthwhile on the boxes I helped admin).
And what's supposed to be the "correct" Python version for 2.8.4 btw?
Python 2.3.5. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYQHZ+gerLs4ltQ4RAqmuAJ4wTTN+NDxjCyE6jmAW0+fyFI0wlwCfWljy YmLhqxr5AUIsM0sIVhYQMV4= =zp61 -----END PGP SIGNATURE-----
On 10/27/05, HaraldFinnås <spamcatcher@lantrix.no> wrote:
WRT maintenance of the system: while at ZC, I actually maintained a separate 'zc-python' RPM which installed itself in '/opt/zc'; all the Zope RPMs I maintained depended on 'zc-python' rather than 'python'.
What's the recommended way of maintaining an extra Python installation for Zope?
You keep it in /usr/local. In fact, when downloading and compiling python, that's the default place it ends up. And /usr/local/bin usually is also first in the path, so zopes ./configure script will find it first. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On 10/27/05, Sascha Ottolski <sascha.ottolski@gallileus.de> wrote:
Am Donnerstag, 27. Oktober 2005 13:20 schrieb Jens Vagelpohl:
You just noted one more disadvantage yourself: The system Python is likely to be out of step with what Zope wants. Furthermore, updates to the system Python or to add-on packages might have unintended consequences for your Zope setup.
well, "might have" is one thing, really experiencing problems is quite different...
Well, I've had severe problems with zope based on an redhat-package,. This was, however, back in 8.0 and 9.0 version of Redhat. Things may have improved. Basically the rpms we used were unstable (our site would crash on random acts (or so it seemed to us)), also on a couple of occations installing other rpms (not from redhat though), would break the python from redhat. This and other bad experiences with redhat/rpms led to a policy with debian and compiled python/zope. I've never looked back. The decision of throwing out redhat and rpms may have been based on my lack of knowledge or incompetence, but I will note that since switching to source-based zope and python (three years or so) and debian we've never experienced any problems that could not be solved within minutes. Except one: We still have a POSKEY error in our Data.fs introduced with the old rpm-based install. I've never managed to delete or locate the object, but it doesn't seem to cause any trouble. So it stays. Just to remind me never to use redhat or rpms. Just my two cents. -- Einar Næss Jensen http://einar.nidelven-it.no/einarblog http://www.homemade.no tlf: +47 90990249
On 28 Oct 2005, at 08:03, Einar Næss Jensen wrote:
doesn't seem to cause any trouble. So it stays. Just to remind me never to use redhat or rpms.
How the bad RPMs you used make you blame RedHat as a whole isn't a jump I can follow... you should be blaming those people who packages the RPMs and not the whole distribution. jens
On 10/28/05, Jens Vagelpohl <jens@dataflake.org> wrote:
On 28 Oct 2005, at 08:03, Einar Næss Jensen wrote:
doesn't seem to cause any trouble. So it stays. Just to remind me never to use redhat or rpms.
How the bad RPMs you used make you blame RedHat as a whole isn't a jump I can follow... you should be blaming those people who packages the RPMs and not the whole distribution.
I'm sure Redhat works fine for many people in a lot of businesscritical solutions. I'm also sure Redhat is good at what they are doing. All I'm saying is: Redhat didn't work for us. Debian do. Also RPM didn't work for us, while instaling from source do. As i remember, redhat 9.0 introduced an error in one of the libraries which would cause the server to hang/reboot from time to time. Also we experienced a corrupt RPM database twice. Not fun at all. Now this may not be redhats fault, but we suffered from it nevertheless and gave an impression of redhat's not something we want. -- -- Einar Næss Jensen http://einar.nidelven-it.no/einarblog http://www.homemade.no tlf: +47 90990249
On 28 Oct 2005, at 10:26, Einar Næss Jensen wrote:
How the bad RPMs you used make you blame RedHat as a whole isn't a jump I can follow... you should be blaming those people who packages the RPMs and not the whole distribution.
I'm sure Redhat works fine for many people in a lot of businesscritical solutions. I'm also sure Redhat is good at what they are doing. All I'm saying is: Redhat didn't work for us. Debian do. Also RPM didn't work for us, while instaling from source do. As i remember, redhat 9.0 introduced an error in one of the libraries which would cause the server to hang/reboot from time to time. Also we experienced a corrupt RPM database twice. Not fun at all. Now this may not be redhats fault, but we suffered from it nevertheless and gave an impression of redhat's not something we want.
The "library error" in RH 9.0 was solved very quickly after its initial release. Updating the environment once in a while and reading the errata helps, and that's a general issue. The "corrupt" RPM database problem can be solved very quickly by either running the requisite BDB tools against it or blowing it away and rebuilding it from scratch. Debian is a great distribution, no doubt, but "X works for us while Y does not" is a misleading statement that creates wrong impressions. It's not RedHat's fault that you weren't up to speed on some of these things. jens
On 10/28/05, Jens Vagelpohl <jens@dataflake.org> wrote:
On 28 Oct 2005, at 10:26, Einar Næss Jensen wrote:
Debian is a great distribution, no doubt, but "X works for us while Y does not" is a misleading statement that creates wrong impressions. It's not RedHat's fault that you weren't up to speed on some of these things.
No. Probably not. We should have had quite another aproach to the new install of redhat 9.0three years ago. The brokne rpm database we didn't manage to recover using the rpm-tools. As i remeber it, a lot of the packages installed software in places where other packages or sourcebased installs would not find it. I think also the up2date procedure with logging in and register your product etc was not what we wanted Also as I remember it, at about the same time Redhat anounced the end of life for several of its products and wanted us to use The new RedHat Enterprise. So there were several factors involved in the change, and probably it didn't have much to do with a bad product from RedHat. Still we dislike Redhat. I think I have written myself way off topic no, so i'll quit here. -- Einar Næss Jensen http://einar.nidelven-it.no/einarblog http://www.homemade.no tlf: +47 90990249
En/na Jens Vagelpohl ha escrit:
The only issues you might ever run into would be problems with the Python that comes with the OS. But then again if you run Zope in production you should never ever use the system Python and build your own instead. The system Python tends to be compiled with weird flags on RH-based distros to suit their own needs for the many Python-based scripts they have in the OS. Don't use it, build your own.
I agree with your opinion, but I have to add that yesterday (that's why I follow-up now to this old thread) I had to build python 2.3.5 on a shiny new x86_64 machine and it's been a bitch to get right. Luckily I found the patches in the (mandriva) rpm for 2.3.4 that solved (or at least it seems so) the issues with lib/lib64 (there are still a couple of tests failing but zope seems to run fine). Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
On 10/26/05, HaraldFinnås <spamcatcher@lantrix.no> wrote:
I'm new to Zope, and I've been playing with 2.8.1, but I really haven't done any real work with it yet. Now I expect to get my new decicated Zope hardware tomorrow, so I have to decide if I should go for 2.8.4 or 3.1.0. Any tips if I should go for the latest and greatest or stick with 2.8?
Depends on what you are going to use it for. So, tell us! :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Depends on what you are going to use it for. So, tell us! :-)
Not sure myself yet. :) There will certainly be a couple of Plone sites, and I plan on writing a simple application for tracking Non-Conformaties, Incident Reports etc (QA related). But based on the responses until now, I've already decided to go with 2.8. I also want to thank everyone who's responded to this thread, especially the OS related comments. :) Regards, Harald
On 10/27/05, HaraldFinnås <spamcatcher@lantrix.no> wrote:
Depends on what you are going to use it for. So, tell us! :-)
Not sure myself yet. :) There will certainly be a couple of Plone sites
Well, Plone doesn't run on Zope 3, so there ya go. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
HaraldFinnås wrote:
(snip)
and I plan on writing a simple application for tracking Non-Conformaties, Incident Reports etc (QA related).
Have you tried Trac ? -- bruno desthuilliers développeur bruno@modulix.org http://www.modulix.com
Am Freitag, 28. Oktober 2005 11:33 schrieb HaraldFinnås:
bruno desthuilliers <bruno@modulix.org> wrote on 28.10.2005 11:09:00:
Have you tried Trac ?
No, but now I will. It's listed as "software development tracking" so I've ignored it. :)
you also might want to take a look at roundup (http://roundup.sourceforge.net/), if you prefer python. Cheers, Sascha -- Gallileus - the power of knowledge Gallileus GmbH http://www.gallileus.info/ Pintschstraße 16 fon +49-(0)30-41 93 43 43 10249 Berlin fax +49-(0)30-41 93 43 45 Germany
On 10/27/05, HaraldFinnås <spamcatcher@lantrix.no> wrote:
Depends on what you are going to use it for. So, tell us! :-)
Not sure myself yet. :) There will certainly be a couple of Plone sites, and I plan on writing a simple application for tracking Non-Conformaties, Incident Reports etc (QA related).
Can I humbly recommend that you don't reinvent the wheel and have a look at www.issuetrackerproduct.com It's really good for QA and general problem reporting.
But based on the responses until now, I've already decided to go with 2.8.
I also want to thank everyone who's responded to this thread, especially the OS related comments. :)
Regards, Harald
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
On Fri, 28 Oct 2005 13:58:31 -0700, Peter Bengtsson <peter@fry-it.com> wrote:
Can I humbly recommend that you don't reinvent the wheel and have a look at
www.issuetrackerproduct.com
It's really good for QA and general problem reporting.
Everybody wants to write their own issue tracker (and in the later stages of this syndrome, their own project management software), as you are well aware of. ;) -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
Alexander Limi wrote:
On Fri, 28 Oct 2005 13:58:31 -0700, Peter Bengtsson <peter@fry-it.com> wrote:
Can I humbly recommend that you don't reinvent the wheel and have a look at
www.issuetrackerproduct.com
It's really good for QA and general problem reporting.
Everybody wants to write their own issue tracker (and in the later stages of this syndrome, their own project management software), as you are well aware of. ;)
Yes, well, after all, this *is* zope and python. The "There should be one-- and preferably only one --obvious way to do it." slogan applies only to language syntax and features. Now, stuff created *with* the language - well, *that* is a *totally* different matter... *wink* /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
participants (13)
-
Alexander Limi -
Andrew Sawyers -
Bill Campbell -
bruno desthuilliers -
Dario Lopez-Kästen -
Einar Næss Jensen -
HaraldFinnås -
Jens Vagelpohl -
Lennart Regebro -
Luca Olivetti -
Peter Bengtsson -
Sascha Ottolski -
Tres Seaver