Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
On Wed, Nov 16, 2011 at 16:12, Laurence Rowe l...@lrowe.co.uk wrote: While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once. Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. But I do think that whatever skin concept Zope 4 has, should be one that can also be used by Plone. Until we get rid of CMF we have to have at least two skin concepts, and that's one to many. Having a third one is no good. If, as Tres say, ++skins++ is overworked and overcomplicated, could we extend plone.browserlayers to have a traverser or something? //Lennart ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
Hi Lennart, I'm not sure if you're not mixing different issues here. Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro rege...@gmail.com: Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Enabling External Methods in skin folders
Hi, I have a bunch of External Methods I'd like to make available in a skin form, and which reload in the same way a page template would if it was modified and the server was in debug mode. What's the recommended product for enabling this now? -Morten ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Enabling External Methods in skin folders
On 17 November 2011 11:28, li...@nidelven-it.no wrote: Hi, I have a bunch of External Methods I'd like to make available in a skin form, and which reload in the same way a page template would if it was modified and the server was in debug mode. External methods should not require restarts either. What's the recommended product for enabling this now? A more robust approach may be to turn your external methods into views, utility functions called from other views, portal_setup upgrade steps, or whatever other purpose they serve. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4 release management
Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. Development Process --- We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
On Thu, Nov 17, 2011 at 11:52, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Hi Lennart, I'm not sure if you're not mixing different issues here. Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro rege...@gmail.com: Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined. Which is exactly what I said above. //Lennart ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4 roadmap
Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS - Remove XML zexp export (davisagli). - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. - Decorators for AccessControl (chaoflow). Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. - Unicode IDs in OFS - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item - New ZMI - Move authentication out to WSGI middleware. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need - Move to Python 3. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
Hi, On 17 November 2011 12:25, Laurence Rowe l...@lrowe.co.uk wrote: Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. w00t :-) +1 from me In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. I think these are sensible principles, but we shouldn't disregard the Zope community outside Plone. Hence, if Zenoss, Silva, ERP5 and others are willing to contribute and maintain code, they should not feel shunted out of the development process. That's not to say we should succumb to indefinite maintenance of all components on the odd chance iet may be needed by someone (we'll have a stable Zope 2 branch for that), but I believe we're stronger as a bigger community with more voices than as a narrow group with only one goal. Development Process --- We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. +1 - GitHub is really useful. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS +1 - Remove XML zexp export (davisagli). +1 - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection +0 - can we articulate the benefit of doing this? - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. +1 - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. +1, though we'll need to balance the desire to be a better WSGI citizen with adding yet more complexity to BaseRequest and BaseResponse. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. +1 - I think WSGI should be the only way to deploy Zope 4. - Decorators for AccessControl (chaoflow). +1 Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. +1, although this will require a lot of fixes in Zope consumers. I think we need a substantially simpler traversal mechanism that people actually understand. I've pdb'd BaseRequest.traverse more times than I care to remember and I still only vaguely understand it. - Unicode IDs in OFS +1 - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item +1, though again will break quite a lot. It's scary from a security perspective, though. - New ZMI +0 - we certainly need better XSRF protection and accessibility and look and feel are not great, though I think we should also consider what we actually use the ZMI for. A low-level object browser is really useful as a last resort admin tool. A number of the other things (like the various CMF tools, PAS, etc) could just as well expose their own views more independently of the ZMI, though we'd still need a way to discover those views. Perhaps something more simliar to the Plone control panel where tools can register views that just appear in a list of things you may need to manage may be useful, but it'll need some way of rooting that to e.g. Plone sites. - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need +1 - Move to Python 3. +0 Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On Thu, Nov 17, 2011 at 7:25 AM, Laurence Rowe l...@lrowe.co.uk wrote: ... (Interesting roadmap snipped) This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. Why on that machine? Why not have the ZF set up git.zope.org? As the primary maintainer of svn.zope.org, I'm not volunteering to have more stuff there. :) I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. I haven't used GitHub myself, but I gather it's good. :) Why not just let them host the project? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 15:50, Jim Fulton j...@zope.com wrote: On Thu, Nov 17, 2011 at 7:25 AM, Laurence Rowe l...@lrowe.co.uk wrote: ... (Interesting roadmap snipped) This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. Why on that machine? Why not have the ZF set up git.zope.org? As the primary maintainer of svn.zope.org, I'm not volunteering to have more stuff there. :) I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. I haven't used GitHub myself, but I gather it's good. :) Why not just let them host the project? That's the conclusion Plone came to. We have experience of running such a migration now, so can probably help. We also have some mirroring for backup happening. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 07:25 AM, Laurence Rowe wrote: Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. I smell something funny in here: if we aren't innovating, why are we making the effort? * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. We should be working to enable the other Zope2-consuming projects to keep up, too. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. As long as any significant body of developers commits to maintaining it, even if the Plone devs don't care any more. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. I would actually argue that Zope4 have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) Note that this question is *not* suitable for loudest voice on zope-dev wins ressolution. The software belongs to the Zope Foundation, which will make any such decision. The work done on github by the Zope4 sprinters in SF should be seen as scratchpads for work which will be migrated back into the canonical repository for each project. A couple of points for consideration: - - bzr and hg are pretty much isomorphic to git WRT this kind of practice. Both have claims on our community which Git does not (hg because it is the tool of choice for Python, bzr because we already use Launchpad). Note that I use Git daily, and the others somewhat less frequently: I'm not speaking from ignorance here. - - Merging feature branches in SVN is not *that* difficult, typically: I've done scores of such merges myself with almost no pain (and the really painful ones would have been pretty much as bad with git / bzr / hg). I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. I would note that hosting Git repositories without Github reduces the value proposition substantially: Git's wins in merging are much less significant than the collaboration workflow changes which github makes possible (tracking pull requests, in particular). Launchpad provides a similar mechanism, albeit one which is less sexy to use. OTOH, github's bug tracker is nothing to write home about, compared to Launchpad. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. Note that we already have the SVN repos for many projects mirrored to Launchpad[1], as well as
Re: [Zope-dev] Zope 4 release management
On 17/11/2011 16:32, Tres Seaver wrote: Note that this question is *not* suitable for loudest voice on zope-dev wins ressolution. The software belongs to the Zope Foundation, which will make any such decision. Small point: the software is open source and anyone who wants can maintain it anywhere they want ;-) If the energy of the people doing the current round of development is focused on Git, I say let them use Git. Provided they keep the svn markers in (and there's no reason not to!) then a git svn dcommit from someome authorized will bring all the work back to wherever the Zope Foundation wants it... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 16:32, Tres Seaver tsea...@palladion.com wrote: * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. I smell something funny in here: if we aren't innovating, why are we making the effort? The innovation is in making it possible for users of Zope 2 to better be part of the wide Python web framework community and use tools and frameworks that are also in use in frameworks like Pylons/Pyramid, Django and TurboGears. The other innovation is in making our platform leaner, more maintainable and easier to understand and debug. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. We should be working to enable the other Zope2-consuming projects to keep up, too. +1 * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. As long as any significant body of developers commits to maintaining it, even if the Plone devs don't care any more. +1 * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. I would actually argue that Zope4 have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. -1 - we'll need something to amalgamate this into a release and we'll need a way to manage and number those releases. We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) Note that this question is *not* suitable for loudest voice on zope-dev wins ressolution. The software belongs to the Zope Foundation, which will make any such decision. The work done on github by the Zope4 sprinters in SF should be seen as scratchpads for work which will be migrated back into the canonical repository for each project. A couple of points for consideration: - - bzr and hg are pretty much isomorphic to git WRT this kind of practice. Both have claims on our community which Git does not (hg because it is the tool of choice for Python, bzr because we already use Launchpad). Note that I use Git daily, and the others somewhat less frequently: I'm not speaking from ignorance here. - - Merging feature branches in SVN is not *that* difficult, typically: I've done scores of such merges myself with almost no pain (and the really painful ones would have been pretty much as bad with git / bzr / hg). In the Plone community, we held a poll. GitHub won hands-down. The second choice was staying with self-hosted SVN GitHub is a big leap forward in software project support. It's also rapidly becoming a de-facto place for many people to look for software. We win if the people we want to encourage to fix bugs or contribute features have a low barrier to entry. Note that this also includes Plone developers working on Plone at this stage, since Plone has now moved to GitHub. So, my personal vote would be for Zope to use GitHub (with a backup mirror), allowing me to have a more integrated toolchain. Personally, I find GitHub substantially better than BitBucket, especially for collaboration, and Launchpad nearly unusable. I'd encourage you to look at usage and growth statistics for the three main hosting/collaboration services. I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. I would note that hosting Git repositories without Github reduces the value proposition substantially: Git's wins in merging are much less significant than the collaboration workflow changes which github makes possible (tracking pull requests, in particular). Launchpad provides a similar mechanism, albeit one which is less sexy to use. OTOH, github's bug tracker is nothing to write home about, compared to Launchpad. Right - Plone has chosen to stick with self-hosted Trac for bug tracking. I'd imagine Lanchpad remaining Zope's bug tracker. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 16:32, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 07:25 AM, Laurence Rowe wrote: Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. I smell something funny in here: if we aren't innovating, why are we making the effort? Zope 3, Grok and Pyramid have all innovated already. This is about making better use of those existing innovations and progressively removing code and dependencies from what is currently Zope2. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. We should be working to enable the other Zope2-consuming projects to keep up, too. I see Zope 4,5... very much as a transition path. I expect the different Zope2 based projects will move down that path at different speeds and that Plone will drive it by virtue of its larger developer base. Most of the other Zope2 based applications do not have the same wide community of developers to draw on. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. As long as any significant body of developers commits to maintaining it, even if the Plone devs don't care any more. Of course. I expect that for some existing Zope2 applications that will be the easier path. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. I would actually argue that Zope4 have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. At some point we will need to make a release that will receive bug fixes. The best point to do that will be the same time as a Plone release. This probably applies more to the central distribution (currently named Zope2), the other subsidiary distributions will certainly go their own way (as we've already seen with DateTime, ZPublisher, etc.), though any included with a Plone release will have a much larger number of people invested in making future bug fix releases. We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) Note that this question is *not* suitable for loudest voice on zope-dev wins ressolution. The software belongs to the Zope Foundation, which will make any such decision. The work done on github by the Zope4 sprinters in SF should be seen as scratchpads for work which will be migrated back into the canonical repository for each project. The current repository on Github is indeed a scratchpad. We would want to do a better job of migrating usernames for a final migration (we would need an svn username - name and email address map.) A couple of points for consideration: - - bzr and hg are pretty much isomorphic to git WRT this kind of practice. Both have claims on our community which Git does not (hg because it is the tool of choice for Python, bzr because we already
Re: [Zope-dev] Zope 4 roadmap
On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS +1 - Remove XML zexp export (davisagli). +1 - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection +0 - can we articulate the benefit of doing this? Currently items are keyed by path in ZCatalog as they must be pulled out with their correct acquisition context (five.intid must also maintain a mapping based on path for the same reason.) When we have parent pointers we will be able to use zope.intid directly instead of five.intid (which many of us have had bad experiences with.) Using intids will mean that renaming or moving items does not require them to be unindexed and reindexed in the portal_catalog as they will maintain their same intid and will open up the possibility of intersecting result sets from a the portal_catalog with a zc.relation catalog. - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. +1 - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. +1, though we'll need to balance the desire to be a better WSGI citizen with adding yet more complexity to BaseRequest and BaseResponse. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. +1 - I think WSGI should be the only way to deploy Zope 4. - Decorators for AccessControl (chaoflow). +1 Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. +1, although this will require a lot of fixes in Zope consumers. I think we need a substantially simpler traversal mechanism that people actually understand. I've pdb'd BaseRequest.traverse more times than I care to remember and I still only vaguely understand it. - Unicode IDs in OFS +1 - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item +1, though again will break quite a lot. It's scary from a security perspective, though. - New ZMI +0 - we certainly need better XSRF protection and accessibility and look and feel are not great, though I think we should also consider what we actually use the ZMI for. A low-level object browser is really useful as a last resort admin tool. A number of the other things (like the various CMF tools, PAS, etc) could just as well expose their own views more independently of the ZMI, though we'd still need a way to discover those views. Perhaps something more simliar to the Plone control panel where tools can register views that just appear in a list of things you may need to manage may be useful, but it'll need some way of rooting that to e.g. Plone sites. - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the
Re: [Zope-dev] Zope 4 roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 02:05 PM, Laurence Rowe wrote: On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: snip - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Note that there is a counter-trend here among the Pyramid crew: many developers *want* tight integration of authentication, particularly the login forms. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need +1 BBB concerns are likely going to keep us from replacing the request entirely. What really matters for re-use is that our requests provide the same commonly-used subset of the WebOb request API. - Move to Python 3. +0 I expect this will only become important several years down the line, but the more we use other people's code who have already ported to Python 3, the less code we will have to port ourselves. FWIW, the port to Python3 of substantial existing web framework code is already a dubious proposition: nearly everybody doing it these days is suffering pain (making their own code more complicated by straddling) in order to gain hypothetical future benefits. I would leave it off the roadmap completely until that landscape changes substantially. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FZywACgkQ+gerLs4ltQ6IcwCgsJ6yQsbLOwOJ18JnV51nxqAg hi4AoIFtnSJqWc5jCPrZdUEVQ1R9N6NO =gaBY -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 19:45, Tres Seaver tsea...@palladion.com wrote: Again, this is a choice to be made by the foundation: any polling will be done by the members of the foundation (this might be the biggest non-election item on the agenda for the next annual meeting). When is the next annual meeting? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 03:14 PM, Laurence Rowe wrote: On 17 November 2011 19:45, Tres Seaver tsea...@palladion.com wrote: Again, this is a choice to be made by the foundation: any polling will be done by the members of the foundation (this might be the biggest non-election item on the agenda for the next annual meeting). When is the next annual meeting? Q1 2012 (date still to be set by the board). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk7FbKcACgkQ+gerLs4ltQ6hHgCYtQIoFi+NTdakkcjiBR4bsOfN 3wCcDerWtgsaNgB/XITcL63wTQYfZus= =nyVH -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 20:20, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 03:14 PM, Laurence Rowe wrote: On 17 November 2011 19:45, Tres Seaver tsea...@palladion.com wrote: Again, this is a choice to be made by the foundation: any polling will be done by the members of the foundation (this might be the biggest non-election item on the agenda for the next annual meeting). When is the next annual meeting? Q1 2012 (date still to be set by the board). Is there any possibility the board could poll the members of the Zope Foundation between annual meetings? We're not looking to migrate the whole of svn.zope.org, only use github for what is essentially a new project. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope-tests - FAILED: 5, OK: 41, UNKNOWN: 1
This is the summary for test reports received on the zope-tests list between 2011-11-16 00:00:00 UTC and 2011-11-17 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux [1]UNKNOWN : Zope-2.12 Python-2.6.6 : Linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit [2]ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [3]ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux [4]Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux [5]Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 [6]winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]UNKNOWN UNKNOWN : Zope-2.12 Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2011-November/052805.html [2]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052798.html [3]FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052790.html [4]FAILED Zope 3.4 Known Good Set / py2.4-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052788.html [5]FAILED Zope 3.4 Known Good Set / py2.5-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052795.html [6]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-November/052825.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On Thu, Nov 17, 2011 at 20:57, Tres Seaver tsea...@palladion.com wrote: FWIW, the port to Python3 of substantial existing web framework code is already a dubious proposition: nearly everybody doing it these days is suffering pain (making their own code more complicated by straddling) in order to gain hypothetical future benefits. The framework as a whole should not straddle versions. Just as we drop backwards incompatibility for Zope 4 and then Zope 5 and then Zope 6, etc, in one of these moves we drop backwards incompatibility by moving from Python 2 to Python 3. That in fact is probably a good reason for a new release all by itself. :-) The same thing goes for Plone. Once Zope X does the move, Plone Y does. Only the packages and products for Plone should need to straddle versions. //Lennart ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 5, OK: 41, UNKNOWN: 1
* Zope tests summarizer nore...@zope.org [2011-11-18 02:00]:
[2]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit
https://mail.zope.org/pipermail/zope-tests/2011-November/052798.html
Module: zope.publisher.tests.test_testing
File
/home/ccomb/ztk1.0dev-slave/Python2.4.6-Linux-64bit/build/src/zope.publisher/src/zope/publisher/tests/test_testing.py,
line 33
with zope.publisher.testing.interaction('foo'):
^
SyntaxError: invalid syntax
I introduced this context manager in zope.publisher, fully aware that it
requires 2.5 at the least (which complies with the ZTK 1.1 specification
of 2.5--2.7).
Thus, I'm really confused why the builder for ZTK 1.0 is picking this up,
I've only bumped the version of zope.publisher in toolkit/trunk, nowhere
else.
Can somebody enlighten me what ZTK 1.0dev actually builds?
Thanks,
Wolfgang
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 5, OK: 41, UNKNOWN: 1
Wolfgang Schnerring wrote: Thus, I'm really confused why the builder for ZTK 1.0 is picking this up, I've only bumped the version of zope.publisher in toolkit/trunk, nowhere else. Can somebody enlighten me what ZTK 1.0dev actually builds? See the [sources] section including comment: http://svn.zope.org/zopetoolkit/branches/1.0/ztk.cfg?rev=123141view=auto Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
