[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Sun Mar 1 12:00:00 2009 UTC to Mon Mar 2 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 1 20:21:00 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011211.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 1 20:23:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011212.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 1 20:25:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011213.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sun Mar 1 20:27:04 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011214.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 1 20:29:04 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011215.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sun Mar 1 20:31:05 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011216.html ___ 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 )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
On Mon, Mar 2, 2009 at 9:59 AM, Martijn Faassen faas...@startifact.com wrote: Also, is there any caching for already processed packages in the include finder code? If no, I'd probably like to contribute some, if I'll use z3c.autoinclude. :) Ah, you're thinking in the same direction. I don't think there's any caching at all yet in autoinclude and that'd be the first thing I'd look at if I were to look into speeding it up. It's just I hadn't run into the pain point yet. That's correct, there's no caching yet. I haven't done any profiling but I'm pretty sure that the pain-point algorithm is z3c.autoinclude.utils.dependencyForDottedName. Some sort of caching ought be a huge help there; the function currently iterates over all sys.path entries for each autoincludeDependencies directive found. Specifically my guess is that utils.py's L81-85 is what would benefit most from a cache, because that's where autoinclude actually peers into the sys.path entries to look for packages. I'd really appreciate it if you could work with Dan to get performance data on autoinclude. I'd be happy to! :) Dan, what do you think? The big reason I haven't tried any optimizations yet is that I haven't found a situation with noticeable slowdown that would let me measure any potential optimizations meaningfully, but it sounds like you've already solved that problem. :) So I think the next step would be to reproduce that situation and measure the execution time before and after we add that caching strategy. Or we could just profile the code rather than relying on my guess. Regards, Ethan ___ 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 )
[Zope-dev] the Zope Framework project
The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 Introduction This document offers suggestions to reorganize our community so we can act more effectively. It does this by trying to clarify what our community is about. The document tries to innovate minimally in concepts and naming in order to provide a relatively small evolutionary step forward that can still make us all work together better. Even though this is an evolutionary step, it will still have a big impact if implemented, so please read on. This document should be relevant to *all* the parts of our community that build web applications, whether they use Zope 2, Zope 3, Grok, Repoze, or applications built on top of these such as Plone or Silva. While it talks a lot about Zope 3 this is because the Zope technology within Zope 3 is used within all these projects. The document wants to recognize this officially. The main innovations in concepts are the name Zope Framework to distinguish it from the Zope 3 application server and the core/extra concept. These are all hopefully descriptions of what are current practices, simply making them more explicit. The biggest innovation is the introduction of a Zope Framework Steering Group as a new entity that will be the steward for the development of this framework. The steering group's primary aim is to facilitate developers in the community so that they can continue to maintain and develop the framework so that it is useful to all of us. In preparing this document I've shown previous versions of it to various members of our community. These people have generally endorsed this effort and given me feedback, which encouraged me to go forward with it. I've edited it further since then, so this is still my proposal and is not automatically endorsed by anyone else. I hope of course that they will reply to endorse this version now! I now make this document public to: * gather more feedback. * let everybody get used to these ideas. * get a positive response so we can move forward with these proposals soon. I hope we can start implementing these suggestions by the end of march or sooner. The Zope project Before we can deconstruct the Zope 3 project, we will look at it in the wider perspective of the Zope project as a whole. What is the Zope project? The Zope project is an umbrella project for a number of sub-projects. Its source code is in a repository managed by the Zope Foundation. Within the Zope project, there are a number of projects that ship full-stack web frameworks (or application servers): * Zope 2 application server * Zope 3 application server * Grok Besides full-stack web frameworks, the Zope project also maintains a lot of libraries such as the ZODB, Zope 2 products, and a lot of Zope 3 libraries. The project also maintains the buildout system. Some projects are based on Zope technology but are not maintained in the repository of the Zope Foundation. These are not considered Zope projects but can nonetheless be important projects to the Zope community. Examples of such important consumers are Plone, Silva and Repoze. Deconstruction of Zope 3 For a long time the community has had a project named Zope 3. This project actually does two things: * maintain and evolve the reusable Zope 3 libraries. * maintain and evolve the Zope 3 web application server. It's clear Zope 3 currently has a dual nature. It is both considered to be a collection of libraries that other projects use and build on, as well as a particular full-stack web framework with a particular user interface (ZMI). There is a community consensus that the perspective on Zope 3 as a collection of libraries is the most central one, as there are a lot of consumers of some of these libraries beyond the Zope 3 application server, such as Zope 2, Plone, Grok, and Repoze. This consensus has driven the splitting up of Zope 3 into a range of independently released libraries. To distinguish between these two perspectives on Zope 3, we will introduce a new term: the Zope Framework. Zope 3 should be used to indicate the Zope 3 application server that is one consumer of these libraries. To be explicit we encourage the use of Zope 3 application server to indicate Zope 3 and discourage the use of Zope 3 to indicate the Zope Framework itself. The Zope Framework -- What is the Zope Framework? It is a set of libraries that can be used in the construction of web application frameworks and web application servers. Use for the web is its primary purpose of the Zope Framework. Many individual libraries within the Zope Framework can also be used for a wide range of other purposes unrelated to web development; this is a secondary purpose of the Zope Framework. The Zope Framework has a number of important consumers from within the wider Zope project, such as Zope 2, Zope 3 and Grok. The Zope Framework project also
Re: [Zope-dev] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
On Mon, Mar 2, 2009 at 11:38 AM, Dan Korostelev nad...@gmail.com wrote: Log message for revision 97423: Update package mailing list address. Remove zpkg stuff. Deleted: zope.file/trunk/src/zope/file/zope.file-configure.zcml === --- zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:09:01 UTC (rev 97422) +++ zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:38:27 UTC (rev 97423) @@ -1 +0,0 @@ -include package=zope.file/ I believe people still use the ZCML slug files like the above. -- Benji York Senior Software Engineer Zope Corporation ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Mar 2, 2009 at 11:38 AM, Dan Korostelev nad...@gmail.com wrote: Log message for revision 97423: Update package mailing list address. Remove zpkg stuff. Deleted: zope.file/trunk/src/zope/file/zope.file-configure.zcml === --- zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:09:01 UTC (rev 97422) +++ zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:38:27 UTC (rev 97423) @@ -1 +0,0 @@ -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrBIu+gerLs4ltQ4RArBSAKDZjWeQPStzXjtnyDUcBpB2kWTxOgCfcNQO J5ocqql0fkyFShEQD1ofQTg= =WWX+ -END 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 Introduction This document offers suggestions to reorganize our community so we can act more effectively. It does this by trying to clarify what our community is about. The document tries to innovate minimally in concepts and naming in order to provide a relatively small evolutionary step forward that can still make us all work together better. Even though this is an evolutionary step, it will still have a big impact if implemented, so please read on. This document should be relevant to *all* the parts of our community that build web applications, whether they use Zope 2, Zope 3, Grok, Repoze, or applications built on top of these such as Plone or Silva. While it talks a lot about Zope 3 this is because the Zope technology within Zope 3 is used within all these projects. The document wants to recognize this officially. The main innovations in concepts are the name Zope Framework to distinguish it from the Zope 3 application server and the core/extra concept. These are all hopefully descriptions of what are current practices, simply making them more explicit. The biggest innovation is the introduction of a Zope Framework Steering Group as a new entity that will be the steward for the development of this framework. The steering group's primary aim is to facilitate developers in the community so that they can continue to maintain and develop the framework so that it is useful to all of us. I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Mon, Mar 2, 2009 at 10:41 PM, Chris McDonough chr...@plope.com wrote: - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. +1 - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. +1 I think this is how Zope 3 packages are evolving now. Every package (library/framework) should be possible to release individually. Regards, Baiju M ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hello, I think we need some sort of stering group (or person(s)). Without rules and decisions to follow we're going to end up like headless chicken running around in the kitchen. Noone knows the direction. Yes sometimes radical changes are good. We're also carrying a lot of old baggage around with Zope3. It is lurking around the corner. Like Shane's zope.pipeline, repoze stuff, etc. BUT at the same we have projects that have to be kept running (and migrated, possibly smoothly) Keeping our packages together at least with a KGS is a must in my opinion. Unless you want yourself to find a working set between the permutations of all required packages versions. Someone releases a new package version and your project just break the next day. That's a nightmare. Monday, March 2, 2009, 6:11:59 PM, you wrote: CM I'm pretty sure a steering group and a rebranding of existing software is not CM going to make us more effective. Here's what I believe would make us more CM effective: CM - encouraging radical change for experimentation purposes, releasing folks from CM various constraints (backwards compatibility, style policing, historical CM ownership) CM - discourage the contribution of stop energy (discourage CM the utterances of don't, stop, this is wrong, CM stop talking about this). CM - focusing on externalizing software; each egg should stand on its own as CM something that a non-Zope person would be able to understand and use CM in isolation. This means documentation for each thing, as well as CM a sane dependency graph. This is *less* about giving this collection CM of software a group name (the zope framework) and more about CM making people *forget* that it is a part of some larger thing. When CM a piece of software does not have a purpose in isolation but still CM lives in its own egg, kill it off and merge it back into whatever CM thing its most closely related to. CM - Stop trying to version control and treat all this software in some CM overall release. Let each piece of software have its own life. Likewise CM if a piece of software does not have its own life, kill it. CM - C CM ___ CM Zope-Dev maillist - Zope-Dev@zope.org CM http://mail.zope.org/mailman/listinfo/zope-dev CM ** No cross posts or HTML encoding! ** CM (Related lists - CM http://mail.zope.org/mailman/listinfo/zope-announce CM http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: There is no remedy for sex but more sex. ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam GROSZER wrote: I think we need some sort of stering group (or person(s)). Without rules and decisions to follow we're going to end up like headless chicken running around in the kitchen. Noone knows the direction. Yes sometimes radical changes are good. We're also carrying a lot of old baggage around with Zope3. It is lurking around the corner. Like Shane's zope.pipeline, repoze stuff, etc. BUT at the same we have projects that have to be kept running (and migrated, possibly smoothly) Keeping our packages together at least with a KGS is a must in my opinion. Unless you want yourself to find a working set between the permutations of all required packages versions. Someone releases a new package version and your project just break the next day. That's a nightmare. It is a nightmare, but not one which a KGS can really fix: sometimes your project needs its *own* KGS. Honestly, the only safe thing for anybody trying to support a large application in production is to run their own index, and do the gatekeeping of packages into it themselves. For instance: - - How many projects are there (community efforts, as well as individual sites / applications) need updates to some of the packages traditionally part of a Zope3 release? I would bet that there are lots of such projects. - - How many projects are there which are going to need a Zope 3.5 release (as opposed to updates to some of the packages traditionally part of Zope3)? I would bet that this set is smaller than the first. For instance, I know that Zope 2.12 *says* it will rely on 3.5, but I don't know what that means, actually. Grok already maintains the moral equivalent of its own KGS, right? - - How many need *all* of Zope3, including the ZMI? I'm betting that set is much smaller than either of the others? - - Of the first set, what is the likelihood that different projects will have conflicting goals about the direction of one or more packages? Given the likelihood that a monolithic Zope 3.5 release is not interesting to lots of the folks who both develop and consume its packages, how much coordination is going to be possible (or even useful) around the idea of another release? Maybe we need to create something more like self-organizing mini-communities around the various packages (or maybe sets). E.g., I would bet that almost everyone active on this list has a stake in zope.interface, zope.component, and their dependencies. Note that *two* of the remaining dependencies (zope.deferredimport, zope.deprecation) are only there to deal with BBB isssues: maybe they should go? Another, zope.proxy, is a blocker for using the packages on non-CPython platforms: should it go? If we consider those packages *in isolation*, as things potentially useful outside any larger framework, the answers to those questions might be different. I'm not so sure that any other package is going to be as widely interesting. I also think that having the *whole* Zope community do oversight oversee on the rest is less useful than having the folks with skin in the game for a particular package steer it. I am unlikely to care much about anything in the Z3 ZMI, for instance, or about a number of other packages in our various namespaces: I could do my job better, *and* keep from interfering in others' interests (e.g., the stop energy Chris mentioned), if we separated out the various areas of concerns. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrCaj+gerLs4ltQ4RAj6QAJ42IfLM5qaEtexebr1FqYW6kG6fmACgk2Lq aKGj9xT5QmUpVKYpV0HeBoQ= =S9Gg -END 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 )
Re: [Zope-dev] Standard request/response API
Jim Fulton wrote: Speaking for myself, I'd be happy to change my code to comform to a python-standard request API assuming that it had enough in it to adapt it to existing APIs. Without having used it myself yet, and without making any claim about it being a Python standard, this makes me think of WebOb by Ian Bicking. It defines request and response implementations around WSGI and has evolved from Paste. -- Thomas ___ 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 )
Re: [Zope-dev] Standard request/response API
On Mar 2, 2009, at 2:08 PM, Thomas Lotze wrote: Jim Fulton wrote: Speaking for myself, I'd be happy to change my code to comform to a python-standard request API assuming that it had enough in it to adapt it to existing APIs. Without having used it myself yet, and without making any claim about it being a Python standard, this makes me think of WebOb by Ian Bicking. It defines request and response implementations around WSGI and has evolved from Paste. Right. That's what I was thinking of. I don't know how much traction it's gotten. Jim -- Jim Fulton Zope Corporation ___ 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 )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: - How many projects are there which are going to need a Zope 3.5 release (as opposed to updates to some of the packages traditionally part of Zope3)? I would bet that this set is smaller than the first. For instance, I know that Zope 2.12 *says* it will rely on 3.5, but I don't know what that means, actually. Grok already maintains the moral equivalent of its own KGS, right? I added the Zope 2.12 depends on Zope 3.5 sentence. What it means at this stage is that Zope2 defines a KGS (in concept but not fleshed out in the way you use it) which directly reuses the Zope 3.5 KGS by virtue of copying it's generated versions.cfg. Just to make this very obvious, this is the versions-zope2.cfg we have: [buildout] extends = versions-zope3.cfg versions = versions [versions] Acquisition = 2.12.0a1 DateTime = 2.11.2 ExtensionClass = 2.11.1 Persistence = 2.11.1 tempstorage = 2.11.1 zLOG = 2.11.1 And that is all there is. While Zope2 probably uses only a third of the packages tracked in the 3.5 KGS, the information about known-good status of the packages it uses, is still very valuable. Technically you would only need to add the above six lines and the Zope2 package itself to the controlled-packages.cfg of zope.release and the KGS part of it would be good for both projects. As the proposed release cycles of both 3.5 and 2.12 are in sync at this point in time, we have actually two options from the point of Zope2: 1. Merge the KGS information into one. We do have the same kind of policies for handling backwards incompatible changes, which largely dictate if new versions of packages are appropriate for inclusion. The generated web presentation of both projects is different of course. 2. Split the Zope 3 KGS into two parts: the Zope Framework bits and the Zope 3 Application Server bits. The Zope Framework as defined as zope.* is far less than Zope2 requires itself. zope.app.testing, zope.app.component, zope.app.form, zope.app.publisher and friends are all used and incur a major buy into the Zope3 Application Server today. So Zope2 does have an interest in a maintained Zope3 KGS and release still. Otherwise we do have to do this work ourselves. If we are to see a refactored publisher and some continued refactoring of dependency graphs, the common set might be getting a lot smaller for a Zope 2.13 / 3.6 release. But this is vapor ware at the current stage. From my Plone perspective I do have even more of an interest in the Zope 3.5 KGS. In the high-level applications I built, z3c.form, zope.intid but also z3c.unconfigure and many more packages are often used. Being able to rely on a KGS of such a wider set of libraries is valuable to me. This however does not mean, that individual packages should be tightly pressed into the needs of such consumers of them. The overhead of tracking incompatible changes, creating maintenance branches where required and releasing maintenance releases of those, can be the burden of a different group of people, than the ones that drive a package forward in its own merit. Hanno ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote at 2009-3-2 12:11 -0500: ... I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. + 1 Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility - 1 I think that a high level of backward compatibility is important. You do not want to continously rewrite your applications because the framework continously drifts away style policing, historical ownership) + 1 - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). + 1 ... although I quite often complain about changes (such as the removal of ZClasses, the (temporary) removal of the logging interface, ) -- Dieter ___ 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 )
Re: [Zope-dev] Standard request/response API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Mar 2, 2009, at 2:08 PM, Thomas Lotze wrote: Jim Fulton wrote: Speaking for myself, I'd be happy to change my code to comform to a python-standard request API assuming that it had enough in it to adapt it to existing APIs. Without having used it myself yet, and without making any claim about it being a Python standard, this makes me think of WebOb by Ian Bicking. It defines request and response implementations around WSGI and has evolved from Paste. Right. That's what I was thinking of. I don't know how much traction it's gotten. Most of tne non-Zope, non-Django frameworks use it. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrE3w+gerLs4ltQ4RAj9OAKCR13Uchl07Ey13sI5c8w50uZNPHACff6rF 6gf6/0+i/zVf/Qryp2rsRYQ= =fKEj -END 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 )
Re: [Zope-dev] the Zope Framework project
Quick Summary: More committees: -1 Everything else: +lots. - I like renaming Zope3, the libraries to The Zope Framework. It makes sense. That part doesn't even need to be official, we can just start calling it this, and those who doesn't like it can call it Zope3 the libraries, and we'll se who wins. :) Democracy at it's best. - This renaming only needs to be official we make KGS releases of it. - KGS releases may be useful (this is for consumers to decide, so it's really the controllers/releasemanager of Zope2, Zope, Grok, Repoze that can say if this is needed or not, and not me). - A steering group for the framework? Euhm? I don't know. I think release managers are needed, and I think a steering group is going to grow out of the community. Having an offical steering group tends to mean that if they don't do anything nothing gets done. It's a bigger risk that the steering group becomes a speed bump than anything else. So -1 on that. So, how to make sure everybody is on the same boat? Well, I think the Plone Strategic Planning Summit 2008 showed the way there. Lets just get all relevant parties into one room and talk loudly an wave their arms around and then go out for beer. Works lurlvely! No steering committee needed. If we still want more structure, we'll get somebody to force us to stick colored dots on big papers on the walls. That whole thing was awesome. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: - A steering group for the framework? Euhm? I don't know. I think release managers are needed, and I think a steering group is going to grow out of the community. Having an offical steering group tends to mean that if they don't do anything nothing gets done. It's a bigger risk that the steering group becomes a speed bump than anything else. So -1 on that. I don't think whether anyone noticed, but currently we don't actually have any clear leadership for Zope 3 development. Discussions often end up in deadlock and then nothing happens. We need a way out of this. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Monday 02 March 2009, Hanno Schlichting wrote: As the proposed release cycles of both 3.5 and 2.12 are in sync at this point in time, we have actually two options from the point of Zope2: 1. Merge the KGS information into one. We do have the same kind of policies for handling backwards incompatible changes, which largely dictate if new versions of packages are appropriate for inclusion. The generated web presentation of both projects is different of course. 2. Split the Zope 3 KGS into two parts: the Zope Framework bits and the Zope 3 Application Server bits. I prefer (2) as I told Martijn in a review of an early draft of the proposal. I would also sign up for the implementation of the split. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Monday 02 March 2009, Hanno Schlichting wrote: This however does not mean, that individual packages should be tightly pressed into the needs of such consumers of them. The overhead of tracking incompatible changes, creating maintenance branches where required and releasing maintenance releases of those, can be the burden of a different group of people, than the ones that drive a package forward in its own merit. +1 specifically on this point and on your response in general. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 00:05, Martijn Faassen faas...@startifact.com wrote: Hi there, Lennart Regebro wrote: - A steering group for the framework? Euhm? I don't know. I think release managers are needed, and I think a steering group is going to grow out of the community. Having an offical steering group tends to mean that if they don't do anything nothing gets done. It's a bigger risk that the steering group becomes a speed bump than anything else. So -1 on that. I don't think whether anyone noticed, but currently we don't actually have any clear leadership for Zope 3 development. Discussions often end up in deadlock and then nothing happens. Sure. But that doesn't mean a steering group is the right solution. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Chris McDonough wrote: [snip] I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. I'm proposing a deconstruction, not a rebranding; a new name is introduced as an entity needs to be named, namely the Zope Framework. What is going to make us more effective is: * a recognition of current reality, i.e. the Zope Framework is not the same as the Zope 3 application server and it serves a far wider audience. * leadership - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) Who is going to make that decision to encourage this? Allow this? You? Me? Who? Right now, *nobody* is making such decisions and nobody can properly get away with saying they allow it. Leadership is a way to get out of it. - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). +1, though a simple discouraging of utterance can't accomplish it by itself. What you need is active leadership that encourages such experimentation. - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. Sure, I agree with all this. Does everybody? What if we get 3 times -1 and 3 times +1 in a discussion on it? This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. Someone's still developing all this software: our community. Someone needs to take responsibility for all this software. I'd say that group is the Zope project. Who decides to kill something off? Who decides whether a merge is okay? Who decides we should have a documentation website for a widely used component. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. If you don't have a list of known good versions you don't know what to test together, unless you maintain a separate list for each library, which would require a lot of coordination overhead which a single list does not. If you say we shouldn't maintain a known good set, then other systems building on top of this will need to maintain their independent lists all by themselves, and there's less chance that Zope 2's, Zope 3's and Grok's list will agree. I think such an agreement is a good idea. Just because *you* tend to use a few selective libraries for your own efforts doesn't mean everybody else is. I think we should definitely support your use case, but not only your use case. A steering group would be aware of these use cases and balance them. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Tres Seaver wrote: [snip] It is a nightmare, but not one which a KGS can really fix: sometimes your project needs its *own* KGS. Sure, that's fine. Grok has its own KGS. And we want reuse. Grok reuses Zope 3's KGS as it doesn't want to do all the research itself and only diverges minimally from the Zope 3 KGS. Grok would prefer to be able to reuse a Zope Framework KGS though as that wouldn't include the ZMI. Honestly, the only safe thing for anybody trying to support a large application in production is to run their own index, and do the gatekeeping of packages into it themselves. There are other distribution methods for application than maintaining indexes; you could do a source release for instance. Software developers have slightly different use cases than a released application does, after all. That said, of course the Zope Framework could provide tools and guidelines that help with such matters. For instance: [examples the document mostly covers] Given the likelihood that a monolithic Zope 3.5 release is not interesting to lots of the folks who both develop and consume its packages, how much coordination is going to be possible (or even useful) around the idea of another release? We need a Zope Framework 3.5 release more than a Zope 3.5 release. The Zope Framework doesn't contain the ZMI. It'd be nice if we could discuss ideas that aren't already covered in the document I wrote :) Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, To people who are suggesting we don't need a steering group nor a name for the Zope Framework, please answer the following questions: * how will the community make hard decisions where lots of people disagree? What is the mechanism for making hard decisions? Don't say Jim makes them because as you may have noticed Jim *hasn't* been making so many of those in recent times. We need to solve this problem. * who reminds us of necessary tasks and directions we're going into? Sometimes the community collectively decides on moving forward. Sometimes it doesn't. Are we really maintaining our issue tracker well, say? * what do we call the codebase that Zope 2, Zope 3 and Grok all share? If your answer is Zope 3, does the ZMI belong to Zope 3 or not? If not, where does it belong? Like it or not, we do have a leadership problem and we do have a muddled way of thinking about Zope 3 in our community. We need to fix them, so I want to hear alternatives from people who don't like my proposal. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, I just realized the irony in this: [Martijn spends a lot of time in trying to solve problems in our community, bothering to consult lots of people and writing up a document] [Chris] I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: Bam, all of Martijn's proposals shot dead entirely. [Chris, again] - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). Chris, do you see any irony in this too? Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Monday 02 March 2009, Martijn Faassen wrote: If you say we shouldn't maintain a known good set, then other systems building on top of this will need to maintain their independent lists all by themselves, and there's less chance that Zope 2's, Zope 3's and Grok's list will agree. I think such an agreement is a good idea. I totally agree. In fact we even have an example of this happening. Zope Corp., at some point, maintained an internal list of package versions (before the KGS existed). The community largely worked with the latest released packages. So both Benji (for ZC) and I were working on zc.testbrowser and we were constantly fixing test breakages when the other person made a checkin, because the different package sets produced different output. Having one overall accepted KGS for the entire community to test with, is a great common denominator that also makes debugging a lot easier. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] the Zope Framework project
Stephan Richter wrote: On Monday 02 March 2009, Hanno Schlichting wrote: [snip] 2. Split the Zope 3 KGS into two parts: the Zope Framework bits and the Zope 3 Application Server bits. I prefer (2) as I told Martijn in a review of an early draft of the proposal. I would also sign up for the implementation of the split. I took your comments into account. To quote from the document: As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. Users of the Zope framework can use this list, but may also diverge from it where they see fit. Other projects (such as the Zope 3 application server and the Grok project) also have a Known Good Sets that expand on the Zope framework list (and may diverge from it). Each of these consumer projects can of course have their own release process, schedule and version numbering. The KGS concept may be expanded beyond this point to help convey more information about the libraries such as deprecation status. Above we described the concept of a Known Good Set for a collection of libraries (or framework). We have currently technical infrastructure that was developed to maintain the KGS for the traditional Zope 3 system. We will need to adjust the technical infrastructure to also support a KGS for the Zope Framework itself, so we can separate it from the KGS for the app server. This means the KGS infrastructure will be usable for more than a single project, and this means other projects may choose to start using this infrastructure as well. I think the Zope Framework should start with any library that's required to make things like Zope 2 and Grok and the Zope 3 app server work. We should then whittle it down over time. We don't have to solve the goal of having a more manageable framework with less libraries in it right away, we just need to define the goal and continue making progress. Perhaps that idea provides unwieldy, and we could define more levels than just core and extra, for instance core, coreplus, and extra, where coreplus is an extension of core needed to support Zope 2. coreplus would be a legacy list though and we should have the goal to get rid of it. I think we should start with a broad core however and get rid of stuff over time, instead of providing a core that nobody really uses right now. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com wrote:
Who is going to make that decision to encourage this? Allow this? You?
Me? Who? Right now, *nobody* is making such decisions and nobody can
properly get away with saying they allow it. Leadership is a way to get
out of it.
I think open source in general has shown two things:
1. Communities can mostly take decisions without having official
authorities to do so. This is hyper democratic.
2. When they can't, usually committees can't either. In those cases
somebody with a deciding vote is needed. This isn't democratic at all,
but efficient.
I think we should think about have offical groups, but for clear
tasks. Such as a Zope 3.6 Release Task Force as a hypothetical
example. It needs to be more than just Stephan Richter. But it should
be for a small, well defined specific task, and they are responsible
not for steering, but for kicking ass! (Their own or others. [So
things get done, you see. {Small joke there. Wasn't very funny was it?
Ah well.}])
+1, though a simple discouraging of utterance can't accomplish it by
itself. What you need is active leadership that encourages such
experimentation.
I don't know about that. I agree with you that there hasn't been
active leadership for a while. But look what has happened without this
active leadership.
* We have two cool new Zope 3 based frameworks. One which throws out
the whole concept of ZCML for doing configuration by radical code
introspection, and as a result making the Zope Framework immensely
more accessible. And another one which experiments with revamping the
way Zope publishes things, and a related effort of rewriting the whole
publisher. Both frameworks have during these experimentation reached
big audiences and gained widespread if still experimental acceptance
in the community.
* Zope 2 has been eggified.
* Buildout has totally massacred all other forms of deployment of Zope projects.
I think experimentation has been if anything more wild than any time
before in my life as a Zopista. I don't think active leadership is
needed to encourage experimentation. I think all that is needed it
what we already have: A less monolithic framework where you can do
wild stuff, together with some seriously smart and wild people.
And we don't need leadership to say which of the experiments to make
non-experimental. That will come automatically. We do need leadership
for making decisions where the community ends up 50/50. In those
cases, most committees will as well. And no, a 3 against 4 vote in a
committee is not a success.
Who decides to kill something off?
If it doesn't get maintained, is dead. I guess you want somebody to
make it official. I'm not sure it's necessary in a component based
reality. With Zope 2 eggified for example, ZClasses gets a separate
module, and it lives as long as somebody maintains it. It's then just
a matter of deciding if it should be a part of the release or not,
which the release manager(s) decide.
Who decides we should have a documentation website for a widely used
component.
Those who writes the documentation in question. :)
To people who are suggesting we don't need a steering group nor a name
for the Zope Framework, please answer the following questions:
* how will the community make hard decisions where lots of people
disagree?
How does the steering committee make hard decisions where lots of
people disagree? If we can't get a serious consensus on something, and
it MUST be decided, then we have a problem no matter what we do. The
traditional open source solution is a benevolent dictator. If that's
not decided, then in worst case have a vote amongst committer members.
How often has this been a problem the last couple of years?
* who reminds us of necessary tasks and directions we're going into?
Sometimes the community collectively decides on moving forward.
Sometimes it doesn't. Are we really maintaining our issue tracker well, say?
No, but then a person should get some sort of responsibility for that.
Note: A person. Not a committee. A committee means a bunch of people
are responsible, which is the same thing as saying that nobody is.
Yeah, yeah , I know. My answer is all peace and love and fluffy
kittens and everybody does whatever they want, but amazingly, it tends
to work! :-) Freedom baby yeah!
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
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 )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote: [snip] Sure. But that doesn't mean a steering group is the right solution. Why not? What do you think is the right solution? I can see a number of alternatives: * a pope that has the leadership role. We had Jim, but the pope's resting. We could institute a new pope. Who? * a small team of people, let's say 2 to 5 that takes on that leadership role, sharing some of the burden and representing a slightly wider range of interests. A steering group. * a voting system. The current system of +1 or -1 from anybody who bothers to reply isn't very effective in my experience; in any controversial discussion the opinions are so mixed nothing tends to happen, or alternatively people just avoid discussions and do things without discussions. Solutions proposed that are harder to understand might get ignored. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 2 Mar 2009, at 16:33, Martijn Faassen wrote: What is the Zope project? The Zope project is an umbrella project for a number of sub-projects. Its source code is in a repository managed by the Zope Foundation. Within the Zope project, there are a number of projects that ship full-stack web frameworks (or application servers): One of the most striking things about the Zope community (imho) is that we don't have a single central presence. There's no Zope conference, people go to PyCon, EuroPython, PloneConf, etc, they hang out in different irc channels (personally I discuss Zope in #plone, #zope, #zope.de, #plone-framework and #repoze), and this mailing list isn't widely read. Yeah, the people are mostly the same, and you know a Zopista from people outside the community, but there doesn't feel like there's a central community. I couldn't tell you what the Zope Foundation does, for example. To distinguish between these two perspectives on Zope 3, we will introduce a new term: the Zope Framework. Zope 3 should be used to indicate the Zope 3 application server that is one consumer of these libraries. To be explicit we encourage the use of Zope 3 application server to indicate Zope 3 and discourage the use of Zope 3 to indicate the Zope Framework itself. +1 The Zope Framework has a central status within the wider Zope project. It is the core Zope technology ingredient to Zope projects such as Zope 2, Zope 3 and Grok. With it's own IRC channel and mailing lists, that become the canonical place for questions about the ZCA, etc? Either way, +1 A library that at some point in time is considered to be part of the Zope Framework is called a core library. The Zope Framework contains those libraries that are reused by a large number of projects, or that the Zope Framework developers want to promote to be being more widely adopted. The Zope Framework developers especially favor inclusions of libraries that are used by other Zope projects. +1 on everything but the want to promote bit - the libraries will be decided by the same developers they'd be promoted to. I'm -1 on framework bloat to help spread libraries. If a package is truly useful as part of the framework it goes in, if it's just cool I don't think it should. The set of libraries that is core can change over time depending on how these libraries evolve and are used. New libraries considered to be core can be added to the set, and existing libraries once considered core can be removed from the set. We should be careful though, as we cannot just drop libraries from the core without considerable thought. A library being in the core signals a level of commitment to this library. Meh, ish. I think if we make it clear enough in advance we should be fine. If a non-core library is widely used compatibility will have to be maintained, but it doesn't mean we should keep it in core if it doesn't deserve it. * if it has a lot of people who contribute to it from our community, it's likely core. -1, it's a zope community package, but not necessarily part of our framework. * if it's something we want to encourage more consumer platforms use, it's likely core. -1, as stated above. Which libraries should be core to start with? Proposed is to take the ``zope.*`` libraries. We can immediately weed out a lot of libraries that aren't considered core, and we can then start the slower processes of adding and removing from that set over time. zope.* is a good start, but I think it'd be more useful to look at what packages are actually used by everyone that's considered to be a framework user. Libraries may have a different status in the core to convey extra information about them, such as deprecation status. How will this be signalled? As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. +1 How will the numbering convention work, currently it is in step with Zope3-the-application-server. Currently intermixed with the Zope Framework core there is code that implements a particular user interface, the Zope 3 ZMI. There is a consensus that these application-like parts should be removed from the core set, as that code typically only sees use by a single consumer (the Zope 3 application server). It is not used by other consumers of the framework. +1 Examples of extra libraries are the hurry.query library for constructing catalog queries, the z3c.form related libraries for form generation, and the grokcore.component library which contains a different way to configure components. Sounds sensible. Any library that is developed for integration with the Zope Framework in the Zope repository can be considered extra; extra is the set of libraries that is not in the
Re: [Zope-dev] Standard request/response API
Hi there, Jim Fulton wrote: There's been some discussion recently about separating the interfaces in zope.publisher from the implementations to facilitate other implementations. I think it would be great to standardize request and response APIs. I'd love to see this extend beyond the Zope community. I believe that there have been some moves to try to do this at the WSGI level, although I haven't kept up with the discussion. See WebOb for Ian Bicking's effort (who did investigate a lot of these APIs including ours in that effort). WebOb is very widely adopted in the WSGI community already and I see no realistic way for us to make any headway there now that it is established. I believe that Pylons, TurboGears 2, repoze.bfg and restish all use it. WebOb is more than an interface but also an implementation and in that sense is quite a bit like our zope.publisher. Even though it's a specific implementation it's on top of WSGI so people can adopt it easily. I think it would be very interesting to look for ways to make bits of Zope work with WebOb somehow. Regards, Martijn ___ 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 )
Re: [Zope-dev] Standard request/response API
Hi there, Tres Seaver wrote: [snip] Right. That's what I was thinking of. I don't know how much traction it's gotten. Most of tne non-Zope, non-Django frameworks use it. Ah, sorry, I missed this line of answering when I answered myself. I agree it's very popular. I think we could get out of the request/response business if we wanted to, but we'd need an evolutionary path to get there. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there,
Lennart Regebro wrote:
On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com wrote:
Who is going to make that decision to encourage this? Allow this? You?
Me? Who? Right now, *nobody* is making such decisions and nobody can
properly get away with saying they allow it. Leadership is a way to get
out of it.
I think open source in general has shown two things:
1. Communities can mostly take decisions without having official
authorities to do so. This is hyper democratic.
2. When they can't, usually committees can't either. In those cases
somebody with a deciding vote is needed. This isn't democratic at all,
but efficient.
Can you stop using the word committee? I didn't use it. A committee is
a bunch of people who has regular meetings, behind closed doors, to make
decisions. That's not what the Steering Group is designed to be. I
thought I was reasonably clear about this in the document.
It's simply a way to distribute the leadership work over multiple
people. Perhaps you're arguing the optimum size of any such group is 1
individual. I'm not convinced that's the case, and in any case I don't
see this individual.
I think we should think about have offical groups, but for clear
tasks. Such as a Zope 3.6 Release Task Force as a hypothetical
example. It needs to be more than just Stephan Richter. But it should
be for a small, well defined specific task, and they are responsible
not for steering, but for kicking ass! (Their own or others. [So
things get done, you see. {Small joke there. Wasn't very funny was it?
Ah well.}])
I'd be quite interested in exploring such options, but I think long-term
leadership still needs to be there. For instance, who defines the
specific task for a task for to work on? Who determines who is in the
task force? Who reminds people of the need to maintain the launchpad
issue tracker?
+1, though a simple discouraging of utterance can't accomplish it by
itself. What you need is active leadership that encourages such
experimentation.
I don't know about that. I agree with you that there hasn't been
active leadership for a while. But look what has happened without this
active leadership.
* We have two cool new Zope 3 based frameworks. One which throws out
the whole concept of ZCML for doing configuration by radical code
introspection, and as a result making the Zope Framework immensely
more accessible. And another one which experiments with revamping the
way Zope publishes things, and a related effort of rewriting the whole
publisher. Both frameworks have during these experimentation reached
big audiences and gained widespread if still experimental acceptance
in the community.
Do you think these frameworks just happened without active leadership? I
can assure you that I've seen lots of leadership from Chris and Tres as
far as Repoze is concerned, and lots of leadership from me as far as
Grok is concerned.
Grok and Repoze are in part *workarounds* for the deficiencies in this
community. For Grok I'm very sure it's a workaround, as I had quite
something to do with it and this was explicit in my mind. It's not
*only* a workaround, but it's definitely a community hack, too.
I see the workarounds as an indication that things in our community
don't work right, instead of signs that it's working. Grok has been
picking up a lot of balls that the zope-dev community had left on the
floor for years (say, an actively maintained website).
That isn't to say groups of people shouldn't move into another space to
do experimentation or go off on a tangent. They should do so. But it
also doesn't mean everything's just fine here. Some of this
experimentation needs to make it back into the common core.
[snip a few examples that are not directly Zope Framework related, but
could be seen as the community adopting Zope Framework technology into
various projects]
I think experimentation has been if anything more wild than any time
before in my life as a Zopista. I don't think active leadership is
needed to encourage experimentation. I think all that is needed it
what we already have: A less monolithic framework where you can do
wild stuff, together with some seriously smart and wild people.
I think you underestimate how monolithic the Zope Framework currently
is, and how much work the *Grok project* put into making it less
monolithic a month ago (and various others, I was gratified to see;
setting a good example is part of leadership). I think it's important to
have someone around who knows what is going on, what people need, and
remind everybody of this regularly and make decisions in the light of
having that overview of what's going on.
And we don't need leadership to say which of the experiments to make
non-experimental. That will come automatically. We do need leadership
for making decisions where the community ends up 50/50. In those
cases, most committees will as well. And no, a 3 against
Re: [Zope-dev] the Zope Framework project
Hi Matthew, Thanks very much for your extensive feedback! Here's some of my feedback. Matthew Wilkes wrote: [snip] * if it has a lot of people who contribute to it from our community, it's likely core. -1, it's a zope community package, but not necessarily part of our framework. What I meant is if lots of people hack on zope.publisher, that means zope.publisher seems core. If it's zc.sourcefactory, that might be interesting too. It's just one signal though among many; usage by a wide range of projects is the most important I'd say. * if it's something we want to encourage more consumer platforms use, it's likely core. -1, as stated above. In a way the Zope Framework is entirely something we want people to use, though. That doesn't mean the Zope Framework should be a platform for the promotion of obscure libraries, but if we add code to it then we're effectively promoting that code for wider use. Since the code wasn't there before, it isn't used yet, after all! I can imagine though that the most common mechanism for something to make it into the core is wide use first, adoption into the core second. Which libraries should be core to start with? Proposed is to take the ``zope.*`` libraries. We can immediately weed out a lot of libraries that aren't considered core, and we can then start the slower processes of adding and removing from that set over time. zope.* is a good start, but I think it'd be more useful to look at what packages are actually used by everyone that's considered to be a framework user. Fully agreed. I just wanted to define a place where we start. [snip] Any library that is developed for integration with the Zope Framework in the Zope repository can be considered extra; extra is the set of libraries that is not in the Zope Framework but can work with it. By having an extra designation we can more easily discuss such libraries. What about other dependencies? Should we have a list of blacklist packages/things that prevent something being called an extra? What if it only works with 1 user of the framework, or 2, or all but 1, where do we draw the line? I'm not sure I understand your questions, could you elaborate? [snip] How is the steering group selected? How long do they serve for? All these questions need to be answered in a way that everyone considers fair for this to work. These are all good questions that indeed need to be answered. I didn't want to presume answering them right away and establish the idea of a steering group first before we go into this. I'll go into my idea for this more below. [snip] In order to determine who is in it we could devise an election procedure by Zope Foundation members. -1, I'm not sure the foundation membership is representative of the users. It could help make said foundation membership more relevant. People need a reason to join the foundation and voting for a steering group is as good as any. The Zope Foundation in the end is a steward for the Zope project as a whole after all. I'd say people put themselves up for election, there is a secret public vote, the foundation review the results and then appoint people. That way they can overrule the public but are informed by them. We have a mechanism set up for the Foundation board election that I believe we can reuse. You need a way to determine who is allowed to vote, though: * the simplest is to take the Foundation membership. We will allow those who care to sign up before, of course. * harder would be to collect data about checkins over a set period and say that those who have done more than n checkins since period X will be qualified to vote. The more I think of it the more I'm in favor of simply using the foundation membership roster though. Let it be relevant to people for a change! How long a steering group should serve I'm not sure about. Perhaps start out with a relatively short period of half a year, and then once we're used to it go for a year-long period? We'll get continuity as it's likely there will be partial overlap at least between elections. If a steering group works well the elections might also be a formality. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi Martijn Betreff: [Zope-dev] the Zope Framework project The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 I generaly agree and give you a big +1 for do something and get a new fresh drive into our development process. I probably will disagree with some details but for myself it's much more important that we look forward and find a better way how we work together. In my point of view we should do the following: precondition: Don't do to much fomral things like write this document. 1. call for participation for a group of people that are interested to work together 2. make progress with the refactoring and dependency cleanup we started 3. show what we did and propose visions and strategies 4. get acceptance for what we this group did. I'm pretty sure that after an intial progress most developer will agree on future visions if the work is well done and is based on the right descissions the working group made. The zope community is not very good in find a way out of problems and tend to discuss things till nothing happens. But all the time if someone just did something it ends probably with a good result. Especialy if some developer work together. See grok, repoze or some z3c.* libraries Let's just call for participation. I'm pretty sure we will find the right road with the people which will contribute their ideas and will help to make progress. btw, I could organize a sprint this spring if some people are interested. Regards Roger Ineichen ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: First of all, I'm not sure what Martijn is saying is necessarily in dichotomy with what you're saying, so we may be going off-topic here. - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) snip - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. As a consumer of various bits of the Zope Framework, I'd be pretty troubled if no-one were to care about backward compatibility or testing a known-good set (what we now call a release) of things that are known to work together. To have to do that myself (or ourselves, in the Plone project) would be a substantial overhead; if we were concerned that backwards compatibility would be ignored, we would have serious concerns about adopting any piece of software coming out of the project. Realistically, there's a release and management overhead that leads to some kind of economy of scale. zope.* is a big namespace. Managing at least some chunks of that namespace as a single unit will likely be beneficial, in terms of getting consensus around evolution, instilling some energy in people and setting goals to get things done, in terms of making releases and managing expectations, and so on. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi Chris Betreff: Re: [Zope-dev] the Zope Framework project Martijn Faassen wrote: The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 Introduction This document offers suggestions to reorganize our community so we can act more effectively. It does this by trying to clarify what our community is about. The document tries to innovate minimally in concepts and naming in order to provide a relatively small evolutionary step forward that can still make us all work together better. Even though this is an evolutionary step, it will still have a big impact if implemented, so please read on. This document should be relevant to *all* the parts of our community that build web applications, whether they use Zope 2, Zope 3, Grok, Repoze, or applications built on top of these such as Plone or Silva. While it talks a lot about Zope 3 this is because the Zope technology within Zope 3 is used within all these projects. The document wants to recognize this officially. The main innovations in concepts are the name Zope Framework to distinguish it from the Zope 3 application server and the core/extra concept. These are all hopefully descriptions of what are current practices, simply making them more explicit. The biggest innovation is the introduction of a Zope Framework Steering Group as a new entity that will be the steward for the development of this framework. The steering group's primary aim is to facilitate developers in the community so that they can continue to maintain and develop the framework so that it is useful to all of us. I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) Do you see any benefit not following a style policy? I think that's the minimum price we have to pay if we work in a community. btw, our zope style policy is defently not very strict and gives most developer enough room for individual coding style. - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. I'm pretty sure you are not using much zope.* or z3c.* packages in your projects as dependency. Your idea is not bad in general, but as a developer which developed all projects based on zope packages your idea could become a nightmare. Years ago I convienced Stephan Richter to start with a new namespace called z3c because we implemented some experimental things like viewlets, templates, macros, pagelets etc. I think this is what happens with repoze and grok too. Now I think it's time to merge the good patterns back to the zope core and replace some old stuff. But we should be carfull with break things if possible. Radical changes and experimental stuff should allways be optional till it's ready, stable and used by a bigger audience. At least it should be very good documented for others which have to update thier projects if we switch to a new concept. Regards Roger Ineichen ___ 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 )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: It is a nightmare, but not one which a KGS can really fix: sometimes your project needs its *own* KGS. Honestly, the only safe thing for anybody trying to support a large application in production is to run their own index, and do the gatekeeping of packages into it themselves. This is true, but not everyone is supporting large packages in production. People need a place to start, if nothing else, and when it comes time to doing a migration project (!), then you need some other known good set to work backwards from. For instance: - - How many projects are there (community efforts, as well as individual sites / applications) need updates to some of the packages traditionally part of a Zope3 release? I would bet that there are lots of such projects. Sure. Having individual eggs is a blessing here. - - How many projects are there which are going to need a Zope 3.5 release (as opposed to updates to some of the packages traditionally part of Zope3)? I would bet that this set is smaller than the first. For instance, I know that Zope 2.12 *says* it will rely on 3.5, but I don't know what that means, actually. Grok already maintains the moral equivalent of its own KGS, right? Certainly, people who start out and want to know which packages work together. Without something like this, managing dependencies becomes very hard. If setuptools is left to pull in whatever it wants, you will probably end up with breakage, unfortunately. - - How many need *all* of Zope3, including the ZMI? I'm betting that set is much smaller than either of the others? Probably none. So having better dependencies would obviously be good. I think you still need a KGS of sorts, but you don't need to depend on *all* of it. :) - - Of the first set, what is the likelihood that different projects will have conflicting goals about the direction of one or more packages? Given the likelihood that a monolithic Zope 3.5 release is not interesting to lots of the folks who both develop and consume its packages, how much coordination is going to be possible (or even useful) around the idea of another release? Maybe we could identify some vectors down the dependency graph that we *do* care about. If we analysed our projects (Plone, and a bunch of add-on products, for instance), we could probably manage to maintain KGS' that say if you want the container interfaces, these packages are known to work together. Maybe we need to create something more like self-organizing mini-communities around the various packages (or maybe sets). Heh... right. ;-) E.g., I would bet that almost everyone active on this list has a stake in zope.interface, zope.component, and their dependencies. Note that *two* of the remaining dependencies (zope.deferredimport, zope.deprecation) are only there to deal with BBB isssues: maybe they should go? Why? They're tiny, and BBB is good. No piece of framework code can be taken seriously if it pretends that people are not going to need backwards compatibility. Another, zope.proxy, is a blocker for using the packages on non-CPython platforms: should it go? If we consider those packages *in isolation*, as things potentially useful outside any larger framework, the answers to those questions might be different. True. I'm not so sure that any other package is going to be as widely interesting. I can think of a few: the container stuff, browser views and pages, page template files, for example. I also think that having the *whole* Zope community do oversight oversee on the rest is less useful than having the folks with skin in the game for a particular package steer it. I am unlikely to care much about anything in the Z3 ZMI, for instance, or about a number of other packages in our various namespaces: I could do my job better, *and* keep from interfering in others' interests (e.g., the stop energy Chris mentioned), if we separated out the various areas of concerns. True. However, someone still needs to think about whether these things are pulling in the same direction, or becoming incompatible with one another. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: What is going to make us more effective is: * a recognition of current reality, i.e. the Zope Framework is not the same as the Zope 3 application server and it serves a far wider audience. * leadership I really couldn't agree more. There's unfortunately a bit of a leadership vacuum in the Zope community. I think Tres and Chris are suggesting we focus leadership around individual packages or sets of packages, and Martijn is suggesting we have something a bit broader focusing on all of Zope. I think the two are not necessarily mutually exclusive. And I'd take any leadership over none at all. Plone, by the way, had a similar problem, and solved it by creating the framework team. This is a rolling body of people who are responsible for putting out calls for and reviewing improvements proposals. They basically report to the release manager, who makes the final call. The release manager is nominated by the framework team, confirmed by the Plone Foundation, and given a small stipend for his troubles. If you say we shouldn't maintain a known good set, then other systems building on top of this will need to maintain their independent lists all by themselves, and there's less chance that Zope 2's, Zope 3's and Grok's list will agree. I think such an agreement is a good idea. +1 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Thank you for the huge effort you expended on this, Martijn. You are right, with Jim taking a rest from his much-appreciated past years as leader, no one is in a position to guide the Zope name. We do have community leaders, such as yourself, but they are guiding other names at the moment. By focusing on reinvigorating the name Zope, I think we have an opportunity to move forward. This can be done loosely but with an opportunity for people such as yourself to take leadership. Zope Foundation members should be encouraged to propose Zope-named umbrella projects. Acceptance should be simple and loose--on the order of, you send an email to the ZF list to request use of a new Zope name, and the default answer to ZF members is yes, unless someone challenges it to a vote within four days, with simple majority rule in the ZF. That's a straw man, but hopefully conveys the idea. For instance and hypothetically, if you tomorrow wanted to start a new project called Zope Rocks that was to be some substrate of Grok, you should be encouraged. Moreover, if you are willing to step up and declare that you are starting something called the Zope Framework that manages a known good set of code, and you hope other projects and people join in and help, that makes sense to me. With what I've seen on the Grok list, you can do a great job as a project leader, generally being positive, open, and motivating. And importantly, it's just a use of the name: Zope. Other ZF developers might come along and say that Martijn character knows nothing--come join be on Zope Super Framework Libraries! I don't think they will, but they could, and would likely be given the same opportunity, given the simple and loose approach I described. That said, I suspect the vast majority of people will be appreciative of your efforts, and I suspect that you'll be able to marshal cooperation among many of the consumers of the current crop of Zope libraries. People that want a leadership position will seek you out and help. Hopefully you can get along. If not, watch out for the competing Zope Super Framework Libraries, coming soon. So that's what I would prefer, instead of the elected steering group. You want it, you do it. And Martijn, I hope you do. And if not, sure, I'll vote for the steering group, hopefully guided by the Plone experience Martin is recounting, just so we have *something*. Gary ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Monday 02 March 2009, Martin Aspeli wrote: Plone, by the way, had a similar problem, and solved it by creating the framework team. This is a rolling body of people who are responsible for putting out calls for and reviewing improvements proposals. They basically report to the release manager, who makes the final call. The release manager is nominated by the framework team, confirmed by the Plone Foundation, and given a small stipend for his troubles. I would like to hear more how the framework team works out for the Plone community, because it is in effect what Martijn is suggesting here. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] the Zope Framework project
Stephan Richter wrote: On Monday 02 March 2009, Martin Aspeli wrote: Plone, by the way, had a similar problem, and solved it by creating the framework team. This is a rolling body of people who are responsible for putting out calls for and reviewing improvements proposals. They basically report to the release manager, who makes the final call. The release manager is nominated by the framework team, confirmed by the Plone Foundation, and given a small stipend for his troubles. I would like to hear more how the framework team works out for the Plone community, because it is in effect what Martijn is suggesting here. Sure. :) In brief: - A team of 5-7 people is selected for each release. - The previous team is responsible for the selection. This involves a general call for nominations, a review, a private discussion to determine the best team (also including former team members), and a public announcement. The team is selected on criteria such as technical competence, knowledge of the stack, commitment, ability to work in a team, and the desire to have a spread of skills and backgrounds on the team. - The new team nominates a release manager (this is usually a formality) to the Plone Foundation Board, who vote on whether to confirm the nomination. - The release manager and framework team work out and publish a schedule. This normally involves: - A call for proposals - A proposal deadline - A deadline for commenting on the merit of the proposals received - A deadline for submitting 'review buildouts' for the team to review the code behind a proposal (if applicable, some proposals are not code related) - A deadline for the team to review the proposals, request fixes/updates form the author, vote, and make a final recommendation to the release manager - A deadline for merging accepted proposals - A general alpha/beta/rc/final release schedule The review process normally involves a primary and secondary reviewer who look at the code in detail and report back to the framework team on their public mailing list. Members then vote +1 or -1. Other community members are encouraged to join the discussion around each proposal, though their votes will not officially count. The release manager does have the final say, and can override the recommendations of the team, though this happens rarely. - The team normally stays on to help steer minor releases, and to select a new team (and new release manager) for the next major release. Regards, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Roger Ineichen wrote: I'm pretty sure you are not using much zope.* or z3c.* packages in your projects as dependency. A good number. zope.index, zope.component, zope.interface, zope.schema, and so on. I don't use 78 of them, like anyone who uses Zope 3, but I do use a good number. Your idea is not bad in general, but as a developer which developed all projects based on zope packages your idea could become a nightmare. Maybe. Years ago I convienced Stephan Richter to start with a new namespace called z3c because we implemented some experimental things like viewlets, templates, macros, pagelets etc. I think this is what happens with repoze and grok too. Now I think it's time to merge the good patterns back to the zope core and replace some old stuff. But we should be carfull with break things if possible. Radical changes and experimental stuff should allways be optional till it's ready, stable and used by a bigger audience. At least it should be very good documented for others which have to update thier projects if we switch to a new concept. Sure. We can be careful, grown-up, conservative, and all that. But I'll note that a) there just really aren't that many people using Zope 3 b) the people that *are* using Zope 3 by itself are capable of maintaining their own index c) the people who *aren't* capable of maintaining their own index are mostly using Zope 2, and that means they're using Zope 3.4 which doesn't really need to change and c) the time for careful, measured effort was over three years ago. IMO, to stay relevant, Zope needs a total overhaul. Martijn's original message was about being effective. It's hard to be effective without being relevant. To gather support and development effort from new people, things need to change drastically. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote: I think Tres and Chris are suggesting we focus leadership around individual packages or sets of packages, Thank you for stating this succinctly; this is exactly right from my perspective. and Martijn is suggesting we have something a bit broader focusing on all of Zope. I think the two are not necessarily mutually exclusive. And I'd take any leadership over none at all. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: Hi there, I just realized the irony in this: [Martijn spends a lot of time in trying to solve problems in our community, bothering to consult lots of people and writing up a document] [Chris] I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: Bam, all of Martijn's proposals shot dead entirely. [Chris, again] - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). Chris, do you see any irony in this too? I really do appreciate the effort, apologies if my response seemed like stop energy. To be honest, I'm just not very interested in talking about solving Zope brand issues anymore. The brand is too large, and too diffuse, and controlled by an entity that is not very connected to the community anymore. Much of the time, the positive value of the brand is often outweighed by its negative value. IMO, we should just try to solve problems we actually have under whatever brand the problem seems to fit under best that *doesn't* have the baggage of the Zope name. We have a good number of brands now (grok, repoze, plone). These brands *do* have leadership and structure and forward momentum. Let's use it. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: Sure. We can be careful, grown-up, conservative, and all that. But I'll note that a) there just really aren't that many people using Zope 3 b) the people that *are* using Zope 3 by itself are capable of maintaining their own index c) the people who *aren't* capable of maintaining their own index are mostly using Zope 2, and that means they're using Zope 3.4 which doesn't really need to change and I'm not sure this is all true: a) Relative to what? I agree it's not a huge community, of course. Still, we're bigger than a lot of other open source projects out there. b) I don't think we can generally assume that. If we do that, then the answer to a) is certainly going to shrink even further. And even those who could (me, for instance), may not want to (me again) c) The Zope 2 and Zope 3/framework release schedules are being co-ordinated. Zope 2.12 will have a KGS of packages aligned with the Zope 3.5 release. I hope that Zope 2.13 or whatever will be able to use a new stable platform of known-to-work-well-together Zope packages, whether you call that Zope 3.6 or not. The ongoing work to refactor dependencies will both make this easier and more important, as getting any old version pulled form PyPI could cause a lot of headaches. Chasing dependencies is about as much fun as a hole in the head. I think there's a market for a somewhat boring and grown up Zope release that cares about backwards compatibility and stability. There's also a market for more radical things. With eggs and individual releases, we have the ability to mix and match between the two in our applications. c) the time for careful, measured effort was over three years ago. IMO, to stay relevant, Zope needs a total overhaul. This may be true, but it's not terribly constructive because it's so non-specific. I don't think Martijn's proposal will stop people from doing more radical things. It wouldn't have stopped you doing repoze.bfg for example. If anything, it may have resulted in a situation where you had someone to talk to about that refactoring that may be able to act and steer Zope development so as to be better aligned with BFG. You and I had a discussion a while back about forking the zope.component ZCML directives, and how it would've been better to work within the boundaries of the Zope packages so that everyone who wanted to lose the zope.security dependency could benefit, rather than fork this and all other configuration that depends on the core ZCML directives. The main reason you had for creating your own package, was the lack of momentum (and/or stop energy) encountered when trying to do this in the Zope world. If there was someone who could both consider BFG's needs in a more objective light, and have the power to actually do something rather than just bicker, then maybe we could've gone a different route on that one. With more and more dependency untangling happening, I am pretty sure this same situation is going to come up again. Martijn's original message was about being effective. It's hard to be effective without being relevant. To gather support and development effort from new people, things need to change drastically. I think things are already changing drastically, even if that happens more in the repoze.* and grok.* namespaces rather than in the zope.* namespaces. I'm really excited to see the amount of TurboGears activity on the repoze-devel list, for example. We need more of that. A steering group that may be able to recognise that doing this is in Zope's interest, and actively act on it, would be a way to make that happen. Without some kind of leadership, it sure as hell *isn't* going to happen. And don't assume there's no desire. Just today, Jim asked whether we should consider using the WebOb request types. That's a pretty radical change in the direction of relevancy to others, wouldn't you agree? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: Martijn Faassen wrote: Hi there, I just realized the irony in this: [Martijn spends a lot of time in trying to solve problems in our community, bothering to consult lots of people and writing up a document] [Chris] I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: Bam, all of Martijn's proposals shot dead entirely. [Chris, again] - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). Chris, do you see any irony in this too? I really do appreciate the effort, apologies if my response seemed like stop energy. To be honest, I'm just not very interested in talking about solving Zope brand issues anymore. The brand is too large, and too diffuse, and controlled by an entity that is not very connected to the community anymore. Much of the time, the positive value of the brand is often outweighed by its negative value. IMO, we should just try to solve problems we actually have under whatever brand the problem seems to fit under best that *doesn't* have the baggage of the Zope name. We have a good number of brands now (grok, repoze, plone). These brands *do* have leadership and structure and forward momentum. Let's use it. I don't think the confusion around Zope 3, the Zope framework and the consumers that happen to use zope.* packages is going to go away just because we ignore it. I totally agree with your pragmatic approach, but that's something quite different. Zope *is* a project. There's enough activity on this list and enough people who commit to svn.zope.org that you can't argue otherwise. And that project needs leadership, which is what Maritjn was really after solving, if I read him correctly. The naming issue is one part of that. Perhaps it would've been better to leave the specifics of naming out of the proposal and let the would-be steering group actually enact this type of change, but then again I don't think Martijn said anything that we don't all agree on, or that isn't already a fact on the ground. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, Well, unless it is... - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. Big yes to both of these, whereby kill it I assume Chris means 'merge it into the project egg where it came from'. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Full disclosure first: I was involved writing up the proposal. On Tue, 2009-03-03 at 00:51 +0100, Martijn Faassen wrote: Lennart Regebro wrote: [snip] Sure. But that doesn't mean a steering group is the right solution. Why not? What do you think is the right solution? I can see a number of alternatives: * a pope that has the leadership role. We had Jim, but the pope's resting. We could institute a new pope. Who? * a small team of people, let's say 2 to 5 that takes on that leadership role, sharing some of the burden and representing a slightly wider range of interests. A steering group. * a voting system. The current system of +1 or -1 from anybody who bothers to reply isn't very effective in my experience; in any controversial discussion the opinions are so mixed nothing tends to happen, or alternatively people just avoid discussions and do things without discussions. Solutions proposed that are harder to understand might get ignored. The voting system option doesn't solve all issues you projected. A voting system can't herd for open issues, for example. So you still would need someone to invoke/maintain the procedures *around* the voting system. For nurturing the community I think people are needed. And I think those people should have a public mandate that they're in charge for certain issues. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 04:13, Martin Aspeli optilude+li...@gmail.com wrote: I wonder what Lennart's solution would be too... Taking a page out of Plone's history: I was evidently unclear: My solution is in three parts: 1. Areas that need somebody responsible should get one. We need somebody to bug people about bugs in the bug tracker. That should be one person, for example. Responsibilities need to be well defined and individual. There isn't anybody called Someone here, so if Someone has to do it, that doesn't get done. 2. To get things done release-wise, I think it would be good to have a release-team for each release. And that would reasonable be different teams for Zope2 and Zope 3, and possibly even for The Zope Framework, obviously most likely with personnel overlaps. 3. To steer, and keep the community on track, I think regular meetings of people in real life will beat any steering group, all hands down. This would best happen at the same time as a conference, and either the Plone conference or PyCon or Europython. I think this will give us enough steering. We aren't as many people as for example Plone or Python. Maybe, if we get everybody on track, we will be, and then we'll have to rethink. But currently the people involved, and the people that need to be steered are so few we can fit them all into one room at a time. And then I do not see why would would need a steering group. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tue, 2009-03-03 at 08:35 +0100, Lennart Regebro wrote: On Tue, Mar 3, 2009 at 04:13, Martin Aspeli optilude+li...@gmail.com wrote: I wonder what Lennart's solution would be too... Taking a page out of Plone's history: I was evidently unclear: My solution is in three parts: 1. Areas that need somebody responsible should get one. We need somebody to bug people about bugs in the bug tracker. That should be one person, for example. Responsibilities need to be well defined and individual. There isn't anybody called Someone here, so if Someone has to do it, that doesn't get done. That's a valid point. However, the steering group was thought of with having fail over in mind so that few people would know about the tasks at hand and can jump in for each other (in a coordinated fashion). Also, the steering group idea doesn't exclude the option of appointing individual people for certain jobs. However, the group should be able to make a better job at keeping things in flow and focused. 2. To get things done release-wise, I think it would be good to have a release-team for each release. And that would reasonable be different teams for Zope2 and Zope 3, and possibly even for The Zope Framework, obviously most likely with personnel overlaps. 3. To steer, and keep the community on track, I think regular meetings of people in real life will beat any steering group, all hands down. This would best happen at the same time as a conference, and either the Plone conference or PyCon or Europython. As much as I prefer discussing with people in real life, there is the notion of no backroom conversations WRT to driving development of an open source project. Having major issues resolved in RL meetings will exclude all those whose schedules don't match and those who can't afford to travel to Far Far Away. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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 )
