--On 21. März 2008 13:39:08 -0700 Timothy Selivanow <[EMAIL PROTECTED]> wrote:
On Fri, 2008-03-21 at 20:09 +0100, Andreas Jung wrote:Hi, speaking as the Zope 2 release manager: I am strongly opposed against splitting Zope yourself into different packages and modules. With Zope 2 depending from various Zope 3 packages (roughly 80-90) we have already the situation to keep track which packages belong together.My concern is more with striping out the non-Zope pieces. If there are pieces of Zope that are useful outside of Zope (e.g. in some other project, or someones personal code...) I thought it would be nice to offer those as a separate piece so that someone could use just that piece. Having 80-90 different RPMs _would_ be rather unmaintainable. I'd only pull out the first few useful ones, and then others by-demand. My biggest concern is removing the non-Zope parts.
In general we want to get rid of 3rd-party packages we don't want to maintain on our own. Right now we have several 3rd-party packages like Docutils in our svn for several reasons. Some of those packages are basically frozen (because we made local changes e.g. for security reasons). So if you rip out those packages you have to guarantee that they will _never_ be updated by a new official package (because local changes might get lost). On the other hand you must ensure that changes to our local
3rd-party packages will be available through your packaging mechanism.As said: this is a challenging task for us right now - it will be even more challenging and more error-prone for outsiders.
As far as Zope2 is concerned, I'll cross that bridge later. Newest technology is /generally/ the focus of Fedora.This will become even more complicated when each Zope 3 package will have its own life-cycle. I doubt that you as a package can keep track in a reliable way with those requirements. It is somewhat hard for me to follow.The Eclipse project has done an awesome job, and so has Fedora in keeping up with it (they actually work very closely together). I'm not concerned with ripping Zope /completely/ apart, but rather I thought /some/ parts might be useful by themselves, like the ZODB for example.
Since Zope (2+3) are officially only blessed for Python 2.4 you'll have problems if you're going with the newest Python 2.5 or even 2.6 version. The trend in all Zope-related projects (Zope 2,3, Grok, Plone) is definitely: self-contained installation. Why self-contained? Different projects require different modules in different versions. Messing a Python installation with e.g. ZODB from different versions will end up in an disaster. So the message of the Zope community is in general: keep your Python installation clean and use zc.buildout or virtualenv for installing your other modules within an isolated environment. This is meanwhile considered best-practice. Using Python eggs and easy_install you have _the official_ tools in your hand for installing 3rd-party packages..that's the Pythonic way to do it, not using some distro packaging tool.
So why can't you leave the Zope source packages as they are? Splitting up Zope into even more packages is even more error-prone. Re-packaged Zope distributions always raised more problems in the past than they really solved. The deployment for Zope-based applications is nowadays based on zc.buildout.So, are you saying that you would rather Zope not be in Fedora, or any other distro, and just leave it up to the user?
This was never my point. For me it would make more sense that the packages would take the official release and re-package it as a whole without splitting it up. Dependency management should happen on our side as a whole, not on the distribution site. I don't know how important Zope distro packages are for users. My personal impression is: not so important. Zope packages at this point might be good for getting into touch with Zope but for deployment packages are basically no used - but correct me if I should be wrong. Since a while we have tools in place to bootstrap Zope 2/3 projects, Plone installations and Grok installations very easily and in a reliable way. I know that those approaches don't comply directly with your package mechanisms but I would expect that the "offical" installation and deployment stories by the Zope community should be taken into account (in some way).
Serious solutions providers never go with distribution-specific packages.Some do, but that's not the focus of me packaging Zope. Since Fedora's focus is not for production (yes, people do use Fedora in production, e.g. NASA, but that is their onus), but rather development and blazing new trails. This would provide more code and utilities for people to use and experiment with.
See above. Distro specific package are perhaps another change for gettting into touch with Zope but I am not sure how important that is. I can imagine that people hear of Zope technology and then visit the related webpage and check the installation notes (which are basically not specific to a dstribution).
One last thought: you might check out the packaging efforts by the Plone project. They provide possibly also packages for Fedora on their own (which includes Zope 2 afaik (the "universal installer")). It might make sense to share experiences with them and leverage from their experiences.
But don't get me wrong. I have nothing against distro-specific packages but they should be done in the right way. "Right" means for the user: they are consistent with the official documentation and best-practices as used within the offical Zope world - "Right" for the supporters within the Zope world: we don't have to deal with issues caused distro-specific packages (e.g. configurations are different from the standard, paths are different from the standard etc.).
Andreas
pgpQrIeQCJCGw.pgp
Description: PGP signature
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
