[Zope-dev] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
I asked this a month ago without getting any responses, so I'll give it one more try: We recently ran into an issue with debug/development mode when making z3c.hashedresource work with Zope2: The package implements different behaviour depending on whether the dev-mode feature is enabled in the ZCML of a Zope3 application, and we sort of expected this feature to be automatically enabled or disabled in a Zope2 application using Five when Zope2 debug-mode is switched on or off, resp. As this doesn't seem to be the case, we were wondering a few things: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? - If so, is it a bug that ZCML dev-mode isn't controlled by Zope2 debug mode in a Five application? Or is it and we're just missing something? - If the the two should be connected but aren't, what's the best way to fix things? Should this be fixed in Five? Otherwise, how to achieve switching on the ZCML dev-mode feature the right way? Independently of these questions, wouldn't it make sense for ZCML to have, in addition to feature and installed, a conditional verb expression that allows referencing a Python expression defined in a module whose boolean value to use for deciding the condition? -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
On 15.09.09 08:00, Thomas Lotze wrote: I asked this a month ago without getting any responses, so I'll give it one more try: We recently ran into an issue with debug/development mode when making z3c.hashedresource work with Zope2: The package implements different behaviour depending on whether the dev-mode feature is enabled in the ZCML of a Zope3 application, and we sort of expected this feature to be automatically enabled or disabled in a Zope2 application using Five when Zope2 debug-mode is switched on or off, resp. As this doesn't seem to be the case, we were wondering a few things: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? What is the ZCML dev-mode? Andreas attachment: lists.vcf___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
Andreas Jung wrote: On 15.09.09 08:00, Thomas Lotze wrote: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? What is the ZCML dev-mode? It's a so-called ZCML feature that can be used with ZCML conditionals. It can be switched on like this: meta:provides feature=devmode/ and used elsewhere like this: adapter zcml:condition=have devmode factory=foo.bar.baz/ -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
On 15.09.09 08:27, Thomas Lotze wrote: Andreas Jung wrote: On 15.09.09 08:00, Thomas Lotze wrote: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? What is the ZCML dev-mode? It's a so-called ZCML feature that can be used with ZCML conditionals. It can be switched on like this: meta:provides feature=devmode/ and used elsewhere like this: adapter zcml:condition=have devmode factory=foo.bar.baz/ I can not remember having seen any support this feature. If you need it, please add it to the Zope 2 trunk (however too late for the Zope 2.12 release, sorry :-)) Andreas attachment: lists.vcf___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
Andreas Jung wrote: I can not remember having seen any support this feature. If you need it, please add it to the Zope 2 trunk I'll see about it ASAP. (however too late for the Zope 2.12 release, sorry :-)) That's fine. -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
On Tue, Sep 15, 2009 at 8:00 AM, Thomas Lotze t...@gocept.com wrote: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? I don't know what kind of functionality is usually switched on by the zcml dev-mode. Are there any common examples? Dev mode in Zope2 is turned on automatically if you run the process in foreground mode and is very common to use. If any of the things controlled by zcml dev mode affect performance or startup time in a noticeable bad way, that would be worrying. If it's only additional logging, development and debug helpers being switched on, that sounds like the same type of functionality. - If so, is it a bug that ZCML dev-mode isn't controlled by Zope2 debug mode in a Five application? Or is it and we're just missing something? Not a bug. Just not a feature implemented yet ;) - If the the two should be connected but aren't, what's the best way to fix things? Should this be fixed in Five? Otherwise, how to achieve switching on the ZCML dev-mode feature the right way? I'd assume you'd need to add some logic into Five for this. Probably register a different zcml handler for the directive as done for most of the handlers. I'd be +1 on this, if there's no performance or otherwise noticeable drawback from it :) Hanno ___ 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] structuring the zopetoolkit SVN layout/web presence
Hey, I think it would be good if we could (eventually) separate the Zope Toolkit development documentation (what's published by docs.zope.org/zopetoolkit now) from the Zope Toolkit release documentation. Zope Toolkit dev documentation: * aimed at people who need to *manage* the development of the ZTK. * talks about release policy, steering group, steering group decisions, etc. * in svn.zope.org/zopetoolkit-dev/trunk (right now in svn.zope.org/zopetoolkit/doc) * we just continue to publish the trunk, tagging will be rare. * might be branched to propose larger restructuring * there's a link in there to individual Zope Toolkit releases, of course. * might be published under docs.zope.org/zopetoolkit/dev Zope Toolkit documentation: * in svn.zope.org/zopetoolkit/trunk * gets published to docs.zope.org/zopetoolkit/release_nr where docs.zope.org/zopetoolkit/current is the lastest release. and possibly docs.zope.org/zopetoolkit/trunk is the trunk. * aimed to developers who want to *use* (bits of) the ZTK. * contains also the locked down list of versions for the Zope toolkit * contains a bit about the ZTK, what it is for, the history up until now. * there's of course a link to the dev documentation too. * contains *usage* documentation for the Zope Toolkit. Tells people a bit about how the packages relate to each other. * contains upgrade notes about how to get from older version of ZTK to this one. * also contains automatically generated information: * the list of packages (autogenerated now) * dependency diagram (use z3c.recipe.depgraph?) * aggregation of change logs? (I have some half-baked scripts that might be useful - I think especially major releases contain upgrade information that would be uesful, i.e. code that moved to another package) Regards, Martijn ___ 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] structuring the zopetoolkit SVN layout/web presence
+1 Jim On Tue, Sep 15, 2009 at 3:57 AM, Martijn Faassen faas...@startifact.com wrote: Hey, I think it would be good if we could (eventually) separate the Zope Toolkit development documentation (what's published by docs.zope.org/zopetoolkit now) from the Zope Toolkit release documentation. Zope Toolkit dev documentation: * aimed at people who need to *manage* the development of the ZTK. * talks about release policy, steering group, steering group decisions, etc. * in svn.zope.org/zopetoolkit-dev/trunk (right now in svn.zope.org/zopetoolkit/doc) * we just continue to publish the trunk, tagging will be rare. * might be branched to propose larger restructuring * there's a link in there to individual Zope Toolkit releases, of course. * might be published under docs.zope.org/zopetoolkit/dev Zope Toolkit documentation: * in svn.zope.org/zopetoolkit/trunk * gets published to docs.zope.org/zopetoolkit/release_nr where docs.zope.org/zopetoolkit/current is the lastest release. and possibly docs.zope.org/zopetoolkit/trunk is the trunk. * aimed to developers who want to *use* (bits of) the ZTK. * contains also the locked down list of versions for the Zope toolkit * contains a bit about the ZTK, what it is for, the history up until now. * there's of course a link to the dev documentation too. * contains *usage* documentation for the Zope Toolkit. Tells people a bit about how the packages relate to each other. * contains upgrade notes about how to get from older version of ZTK to this one. * also contains automatically generated information: * the list of packages (autogenerated now) * dependency diagram (use z3c.recipe.depgraph?) * aggregation of change logs? (I have some half-baked scripts that might be useful - I think especially major releases contain upgrade information that would be uesful, i.e. code that moved to another package) Regards, Martijn ___ Zope-Dev maillist - zope-...@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 ) -- Jim Fulton ___ 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] Subversion externals versus mirroring
On 2009-09-11, Sebastien Douche sdou...@gmail.com wrote: Caution with the actual workflow, 2 differences between SVN and Hg : - you cannot check out partial repository - external does not exist Missing externals has been a pain point for me. There are however buildout recipes that can pull in externals for you from buildout. infrae.subversion does it (and can turn the downloaded stuff into a development egg at the same time), Balasz Ree has a bzr recipe. I'm betting there's a mercurial one, also (and otherwise I'll build one if needed) :-) There remains a small pain point: you have to basically run buildout to update the externals in that way. A simple svn up/bzr up/etc doesn't update the externals... But there are of course lots of advantages to distributed systems that outweigh the small pain. So: missing externals are solveable if we all use buildout :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] official release policy ZTK is still not changed
On 2009-09-11, Benji York be...@zope.com wrote: On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton j...@zope.com wrote: On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen faas...@startifact.com wrote: * I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools. The proposed change would make this tool simpler. zest.releaser's job would not become simpler. It currently grabs the version (with or without dev marker) from either version.txt (old projects or non-setup.py stuff) or the setup.py. Suddenly it is '0' instead of '1.2dev'. What's it going to suggest as new version? Yeah, it grabs the tags from subversion so it *can* make a decent guess. But you cannot easily register I want this to become 2.0 anymore. More importantly, it makes things simpler for people who don't use the tool. +1 -- reducing the number of tools necessary to (easily) accomplish a particular task is valuable. I'd rather do a bin/fullrelease (one step) instead of following a 7-step method to properly release a package. And setting the version to 0 only adds one more potential error point: where do you look up the next version? Someone might have forgotten to tag the previous release (if you look at tags) or might have forgotten to update the CHANGES.txt (if you look at that) or have not uploaded it to pypi (if you look at that). People aren't that good at repetitive tasks. Use a small tool like zest.releaser (or collective.releaser if you don't mind occasional 1.2-r1234 releases as that uses the setup.cfg for the dev marker). Use such a tool and you won't have to bash yourself or co-workers for - forgetting to tag a release. - forgetting to use 'register' in 'sdist upload register' so that the documentation on pypi isn't updated. - forgetting to remove a dev marker (or changing the 0). - Updating the changelog, preparing it for the next changes. Well, we might as well do away with buildout. Reducing the number of tools... Just do it by hand! Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] Subversion externals versus mirroring
On 14.09.09 20:02, Gary Poster wrote: On Sep 11, 2009, at 9:34 AM, Chris Withers wrote: Martijn Faassen wrote: Christian Theune wrote: [snip] Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging. Please keep up posted. We have a standing offer from Canonical to host our stuff in bzr. The move of the Python core developers to mercurial is also interesting. I've been impressed with TortoiseHg so far (after a few initial hiccups) and it looks like they're aiming to be cross platform with it, which is a pretty big draw, although the MacOS port isn't ready yet... How has TortoiseBzr progressed? My understanding is that TortoiseBzr has largely withered on the vine in favor of a new effort: BzrExplorer, based on Qt, and running on Linux/Windows/Mac. http://bazaar-vcs.org/BzrExplorer That page has links to lots of information. The very little information I have is based on those pages, so, for now, please look there for now rather than asking me anything. Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers. One personal aspect I would like to throw into the discussion: Although it is possible to use hg/bzr/svn in parallel within a project and a buildout, I am completely against having a mixture of SVN+HG or SVN+BZR within a Plone project (where Zope stuff is coming from BZR or HG) and the Plone stuff from SVN..if we want/need to switch away from SVN then all other related projects should switch as well. Andreas attachment: lists.vcf___ 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] Subversion externals versus mirroring
On 9/15/09 10:33 , Reinout van Rees wrote: On 2009-09-11, Sebastien Douchesdou...@gmail.com wrote: Caution with the actual workflow, 2 differences between SVN and Hg : - you cannot check out partial repository - external does not exist Missing externals has been a pain point for me. There are however buildout recipes that can pull in externals for you from buildout. infrae.subversion does it (and can turn the downloaded stuff into a development egg at the same time), Balasz Ree has a bzr recipe. I'm betting there's a mercurial one, also (and otherwise I'll build one if needed) :-) And mr.developer can handle them all. This only solves the problem partially though: most of my projects use svn externals to pull in CSS, javascript and other resources from an external prototype. That is not supported by those zc.buildout recipes: they can only checkout a whole package. In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now. For that reason I am still -1 on switching to git/bzr/hg/etc. Wichert. ___ 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] official release policy ZTK is still not changed
On 2009-09-11, Martijn Faassen faas...@startifact.com wrote: Jim Fulton wrote: but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1 Reasons: * it breaks dependencies on development versions which have version requirements in it (see Wichert's comments on the original thread). Really important. When I add an external to a trunk/branch version of something as I need to fix/improve something, I immediately change the version requirement in the setup.py. What's better? Do a my.package 2.7 or leaving it at my.package = 2.5 and trusting your memory to change that afterwards? You'll surely see the my.package == 0 when releasing (as stuff breaks), which means more work as you have to look up version numbers again. Make it easy to do the right thing instead of making it more work, I'd say. The '0' means it is easier (human nature...) to just leave the version requirement in the setup.py alone as it is too much hassle. * I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools. In case the policy is changed, I'll of course fix up the tool. I'm still -1, though :-) This way it is much easier to help new people get up to speed in our community, maintain consistent practices, and people already in our community will also have an easier time keeping track of what's going on. A '0' version does little to help people pitching in with a bugfix. They'll have to figure out themselves what the version is supposed to be. If you pick the my.project/branches/reinout-fixthingy branch and the version is set to '0', you'll have to figure out what version of the branch is. A 2.8 bugfix branch? A feature brach off the trunk? The '0' seems especially unclear for branches. [I hope people who appreciate having such a policy will chip in here and say yes, I want a written-down policy, please so it isn't just me who is telling Jim this.] for i in range(20): print yes, I want a written-down policy, please Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] where is zc.zservertracelog 1.2.0?
On 2009-09-11, Gary Poster gary.pos...@gmail.com wrote:
Hi. pypi advertises http://pypi.python.org/pypi/zc.zservertracelog/1.2.0
but there is no download to be found! :-) Could whoever made the
release add the download?
Related to the recent 1.2dev or 0 discussion where zest.releaser was
mentioned: this is a great example where small inobtrusive tools like
zest.releaser and collective.releaser help a lot.
The tool won't forget to make the upload!
Don't make things unclear ('0' instead of '1.2dev') to save you one edit
action upon releasing as it is easier for doing a release by hand.
Especially if doing a release by hand means several unneeded manual edit
actions (updating changelog with release date and a new section, for instance)
that you wouldn't need by using a small tool.
Reinout
--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets
___
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] Open issues ported to Launchpad blueprints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in the face of organizing the ZTK 1.0 release Hanno and I ported the open issues as blueprints to Launchpad (and added some more suggestions along the way). You can see them here: https://blueprints.edge.launchpad.net/zopetoolkit So, new proposals should also get registered there. If you need to write detailed specification, please put it in the proposals section in the Zope Toolkit documentation and link the blueprint to the resulting HTML page on docs.zope.org. Christian - -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqvYSUACgkQdUt9X/gknwIKbQCfVnCD6GZzq8pN4ZWGXSaYbfsA QIQAn14wOQF9NzLdHJuT8Txq4rq57Ed4 =mQqc -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] Subversion externals versus mirroring
On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote: In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now. FWIW, this is some variable degree of wrong. 1) Everyone cannot merge changes right now: only developers that have commit privileges can do that. That's what you meant, I expect. 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Generally, I'd be surprised to learn that Bzr/Launchpad were alone in supporting this, but they are the only ones I can vouch for. For instance, I'm almost positive that github also allows you to have multiple committers to a single branch, though I don't remember the mechanism. Gary ___ 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] Subversion externals versus mirroring
On 9/15/09 13:56 , Gary Poster wrote: On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote: In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now. FWIW, this is some variable degree of wrong. 1) Everyone cannot merge changes right now: only developers that have commit privileges can do that. That's what you meant, I expect. Indeed. 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Indeed, but most people do not do that. With our current setup once you get commit privileges you immediately have access to an entire world of things. With DVCS hosting systems that people use you have would have to request access for every single package. That is cumbersome and adds a lot of delay so people don't do that and fork instead. The end result is a lot more forks, half of which will probably never be merged back or seen by others. Wichert. ___ 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: 8 OK
Summary of messages to the zope-tests list. Period Mon Sep 14 12:00:00 2009 UTC to Tue Sep 15 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Sep 14 20:43:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012544.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Sep 14 20:45:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012545.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Mon Sep 14 20:47:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012546.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon Sep 14 20:49:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012547.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Mon Sep 14 20:51:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012548.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Mon Sep 14 20:53:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012549.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Mon Sep 14 20:55:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012550.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Mon Sep 14 20:57:42 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012551.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] Subversion externals versus mirroring
On Sep 15, 2009, at 7:59 AM, Wichert Akkerman wrote: On 9/15/09 13:56 , Gary Poster wrote: 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Indeed, but most people do not do that. With our current setup once you get commit privileges you immediately have access to an entire world of things. With DVCS hosting systems that people use you have would have to request access for every single package. That is cumbersome and adds a lot of delay so people don't do that and fork instead. The end result is a lot more forks, half of which will probably never be merged back or seen by others. Perhaps that is the way other systems work; again, I can only vouch for Bzr/Launchpad, and your description is incorrect for us. With Bzr/Launchpad, a single time for each project, you would designate an appropriate committer team as having commit privileges for that project. Then, for each person that should be able to commit to all of the projects, you add them to that team. This is how we have our open-source Zope-friendly lazr.* packages set up. We have a single team for committers, which has privileges for all of our lazr.* packages. When a new person should be able to commit to all of the packages in the lazr.* effort, we just add them to that team. See, for instance, the trunk of lazr.delegates: https://code.launchpad.net/~lazr-developers/lazr.delegates/trunk . You simply need to be added to lazr-developers ( https://launchpad.net/~lazr-developers ) in order to commit to this and any of the other similarly- configured lazr.* projects. Gary ___ 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] official release policy ZTK is still not changed
On Tuesday 15 September 2009, Reinout van Rees wrote: On 2009-09-11, Martijn Faassen faas...@startifact.com wrote: Jim Fulton wrote: but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1 -1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] Subversion externals versus mirroring
On Tue, Sep 15, 2009 at 07:56:42AM -0400, Gary Poster wrote: Generally, I'd be surprised to learn that Bzr/Launchpad were alone in supporting this, but they are the only ones I can vouch for. For instance, I'm almost positive that github also allows you to have multiple committers to a single branch, though I don't remember the mechanism. bitbucket and github both support this, yes. (And thus presumably any repository running mercurial or git, though I don't know how to admin them.) -- Paul Winkler http://www.slinkp.com ___ 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] Update on ztk kgs: Python 2.6 issues
On Tue, Sep 15, 2009 at 12:08 PM, Patrick Gerken do3cc...@googlemail.com wrote: Hi, I have removed that profiler for python2.6 My understanding of the python api is, that we were using an undocumented feature to merge two hotshot profiler results. Since nobody maintains hotshot any longer, there probably won't be anybody adding this feature officially. Tests on 2.6 work for me now. Thanks. That's probably the right first step. Does this mean we're permanently removing this feature? That would be OK with me. Jim -- Jim Fulton ___ 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] official release policy ZTK is still not changed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Tuesday 15 September 2009, Reinout van Rees wrote: On 2009-09-11, Martijn Faassen faas...@startifact.com wrote: Jim Fulton wrote: but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1 -1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing. If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right? I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. 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 iD8DBQFKr/9i+gerLs4ltQ4RArnjAJsEFhiKH6pyOx9AYsoZVP1W0N3U5wCgivGn jc897TMxlf9XAmW4K/TJjag= =/fhs -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] official release policy ZTK is still not changed
On Tue, Sep 15, 2009 at 4:56 PM, Tres Seaver tsea...@palladion.com wrote: I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. Well said. -- Benji York Senior Software Engineer Zope Corporation ___ 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] ZTK test failures - zope.testing
Hi from the Grok sprint, Jan-Jaap from thehealthagency and myself spent some time on getting extensive buildbot coverage for the ZTK (and many other Zope things) going. It's all three Python versions (2.4 - 2.6) on all major platforms (Windows, Mac OS, 32-bit Ubuntu + 64-bit Ubuntu). You can see the overall buildout at: http://dev.thehealthagency.com/buildbot/waterfall (the url is also documented in the ZTK docs). Or if you just interested in the ZTK part of it, you can look at [1]. We are down to zero-build problems for the ZTK and just one test failure. This is in zope.testing in testrunner-layers-buff.txt. You can look at the test result at [2]. It looks like some sort of timing issue for parallel test runs. On Windows there seems to be some more related test failures [3]. Could someone who knows more about the subprocess support in zope.testing have a look at those? Once that failure is gone, we should have green lights on the ZTK on all platforms and Python versions :) Thanks, Hanno [1] http://dev.thehealthagency.com/buildbot/waterfall?branch=builder=ztk-win-py2.4+slave-win-py2.4builder=ztk+slave-osx-py2.4builder=ztk+slave-osx-py2.5builder=ztk+slave-osx-py2.6builder=ztk+slave-ubuntu32-py2.4builder=ztk+slave-ubuntu32-py2.5builder=ztk+slave-ubuntu32-py2.6builder=ztk+slave-ubuntu64-py2.4builder=ztk+slave-ubuntu64-py2.5builder=ztk+slave-ubuntu64-py2.6builder=ztk-win-py2.6+slave-win-py2.6builder=ztk-win-py2.5+slave-win-py2.5reload=none [2] http://dev.thehealthagency.com/buildbot/builders/ztk%20slave-ubuntu32-py2.6/builds/8/steps/test/logs/stdio [3] http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio ___ 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] official release policy ZTK is still not changed
On 2009-09-15, Tres Seaver tsea...@palladion.com wrote: If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right? Checking the changelog: yes, do that. And again, zest.releaser takes the make doing the right thing simple approach by providing a lasttagdiff command to show the diff of the current checkout with the last tag it can find in svn. For the common case, this helps a lot. And updating the release date? Yes, zest.releaser does that for you so that you never ever forget it. (And yes, it first shows you a diff and asks you to press yes so you do get to review it and you're constantly reminded about what's happening). I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. Seen from a different viewpoint, this also makes it an unappetizing yucky event. Human nature then quickly takes over and tries to find corners to cut. And human nature includes mistakes, so stuff is forgotten (like that forgotten upload to pypi we saw here on the mailinglist). Tres, is your preference something personal or is it something you'd like to see everyone adopt? In that case my zest.releaser would be quite high on your things-to-torture list :-) Which would sadden me a bit as my goals were: - make it easy to do the good thing (like an easy diff with the last tag) - make it painless and take the hassle out of it - get more good releases. The '0' would be something zest.releaser could code around, so it would defeat the purpose of making it harder. The loss of clarity would still be there. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] ZTK test failures - zope.testing
Hi Hanno, On Tue, Sep 15, 2009 at 6:42 PM, Hanno Schlichting ha...@hannosch.eu wrote: We are down to zero-build problems for the ZTK and just one test failure. This is in zope.testing in testrunner-layers-buff.txt. That smells like something Gary has touched recently. -- Sidnei ___ 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] Apache rewrite - HTTP_Host redirect issue
Hi Dan
I have an issue with the latest changes in
zope.publisher.http.py
The redirect method in HTTPResponse http.py line: 880
forces a ValueError. Because the Apache HTTP_HOST
and the target_host to not compare.
def redirect(self, location, status=None, trusted=False):
location = str(location)
if not trusted:
scheme, target_host, path, query, fragment = (
urlparse.urlsplit(location))
if target_host and target_host != self._request.get('HTTP_HOST'):
raise ValueError(
Untrusted redirect to host %r not allowed. % target_host)
Apache uses DOMAIN in HTTP_HOST like expected
and the method used with urlparse.urlsplit(location)
returns DOMAIN:PORT as target_host value.
I'm not sure if this is an issue or a bad Apache rewrite
configuration.
As far as I see we should remove the PORT part from the
target_host value. right?
I'm not sure if remove the port info from the value
if this is contra productive for security. If so
what is the correct concept for make the Apache
rewrite work? I guess there is no way to support both.
btw, I'll run into this problem after a redirect during
authentication login form to the cameform url. This
should be reproducable by any other apache (port) rewrite setup.
Regards
Roger Ineichen
_
Projekt01 GmbH
www.projekt01.ch
Boesch 65
6331 Hünenberg
phone +41 (0)41 781 01 78
mobile+41 (0)79 340 52 32
fax +41 (0)41 781 00 78
email roger.ineic...@projekt01.ch
_
END OF MESSAGE
___
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] official release policy ZTK is still not changed
Hi Betreff: Re: [Zope-dev] official release policy ZTK is still not changed -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Tuesday 15 September 2009, Reinout van Rees wrote: On 2009-09-11, Martijn Faassen faas...@startifact.com wrote: Jim Fulton wrote: but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1 -1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing. If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right? I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. I propose to delete the CHANGES.txt file after we tagged the trunk. This will force people to carefully read all the revisions till they will find the removed CHANGES.txt file for restore them. And of corse we should add a comit hook in subversion which will not allow to tag a trunk without a CHANGES.txt file. Hard enough? just kidding, Roger Ineichen ___ 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] ZTK test failures - zope.testing
On Sep 15, 2009, at 6:33 PM, Sidnei da Silva wrote: Hi Hanno, On Tue, Sep 15, 2009 at 6:42 PM, Hanno Schlichting ha...@hannosch.eu wrote: We are down to zero-build problems for the ZTK and just one test failure. This is in zope.testing in testrunner-layers-buff.txt. That smells like something Gary has touched recently. Meh, yes indeed--for all but one failure (see below). The Ubuntu one should be easy to fix. The Windows ones may be tied up with \n \r fun. It should be trivial too, though I'll need to get a Windows VM back up--or request aid from Sidnei. ;-) I'll address these issues tomorrow. However, there is a Windows failure that I don't think is on my plate, and I'd appreciate someone else looking at it: zope.testing-3.8.2- py2.4.egg\zope\testing\testrunner\testrunner-test-selection.txt, line 166, in testrunner-test-selection.txt . That's the very last one on http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio . If someone else can address that last one, and I address the rest, we can have a new release. Gary ___ 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 )
