Re: [Zope-dev] Apache rewrite - HTTP_Host redirect issue
On 2009-9-16 01:15, Roger Ineichen wrote:
> 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 in HTTP_HOST like expected
> and the method used with urlparse.urlsplit(location)
> returns as target_host value.
I suspect Apache does use DOMAIN:PORT if the port is a non-standard
port, ie http over anything other than port 80 or https over something
other than port 443.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
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 > 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 )
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 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 )
[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 in HTTP_HOST like expected
and the method used with urlparse.urlsplit(location)
returns 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] ZTK test failures - zope.testing
Hi Hanno, On Tue, Sep 15, 2009 at 6:42 PM, Hanno Schlichting 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 )
Re: [Zope-dev] official release policy ZTK is still not changed
On 2009-09-15, Tres Seaver 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 )
[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.4&builder=ztk+slave-osx-py2.4&builder=ztk+slave-osx-py2.5&builder=ztk+slave-osx-py2.6&builder=ztk+slave-ubuntu32-py2.4&builder=ztk+slave-ubuntu32-py2.5&builder=ztk+slave-ubuntu32-py2.6&builder=ztk+slave-ubuntu64-py2.4&builder=ztk+slave-ubuntu64-py2.5&builder=ztk+slave-ubuntu64-py2.6&builder=ztk-win-py2.6+slave-win-py2.6&builder=ztk-win-py2.5+slave-win-py2.5&reload=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 Tue, Sep 15, 2009 at 4:56 PM, Tres Seaver 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 )
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 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 Design"http://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] Update on ztk kgs: Python 2.6 issues
On Tue, Sep 15, 2009 at 12:08 PM, Patrick Gerken 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] 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
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. Best regards, Patrick On Sun, Aug 16, 2009 at 18:02, Marius Gedminas wrote: > On Sat, Aug 15, 2009 at 06:55:17PM -0400, Jim Fulton wrote: >> I've gotten the ztk kgs tests to pass with Python 2.5 on Mac OS X. > > Yay! > >> I've got them mostly passing with on Python 2.6. > > Double yay! > >> The only failure I'm >> getting is for zope.testing and it's due to a Python 2.6 hotshot bug: >> >> http://bugs.python.org/issue6710 >> >> I'm not sure what to do about this. Perhaps I should disable this >> test, or maybe even the feature for Python 2.6. > > Sounds about right. Python 2.6 has cProfile, which is (supposedly) > better than hotshot. > >> When building, I'm getting some deprecation warnings: >> >> /Users/jim/.buildout/eggs/infrae.subversion-1.4.5-py2.6.egg/infrae/subversion/Common.py:4: >> DeprecationWarning: the sets module is deprecated >> from sets import Set # For python 2.3 compatibility >> /Users/jim/.buildout/eggs/z3c.recipe.compattest-0.7-py2.6.egg/z3c/recipe/compattest/recipe.py:4: >> DeprecationWarning: The popen2 module is deprecated. Use the >> subprocess module. >> import popen2 >> >> It would be great if someone would fix these. :) >> >> When running the tests, the only deprecation warnings are from >> twisted, which we can't do anything about. >> >> BTW, if you want to try this yourself, use the buildout at: >> >> svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs >> >> Jim > > Marius Gedminas > -- > http://pov.lt/ -- Zope 3 consulting and development > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iD8DBQFKiC2bkVdEXeem148RAqBqAJ9OzOs54teKwKNZnFKzgu8oOVmYhwCdEx6B > uEo3hYRB9E1rbXZ7AW+gp8c= > =nlZQ > -END PGP SIGNATURE- > > ___ > Zope-Dev maillist - zope-...@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > > ___ Zope-Dev 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 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 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 )
[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 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 )
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 )
[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] where is zc.zservertracelog 1.2.0?
On 2009-09-11, Gary Poster 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 )
Re: [Zope-dev] official release policy ZTK is still not changed
On 2009-09-11, Martijn Faassen 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] Subversion externals versus mirroring
Andreas Jung wrote: > 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. That's not our decision to make ;-) I agree about using homogeneous source control within a project, but if two dependencies of that project use different source control systems, it's trivial to take an export of one of them. In fact, this "vendor branch" policy is actually recommended by the subversion guys even if you're using the same source control system... 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] Subversion externals versus mirroring
On 9/15/09 10:33 , Reinout van Rees wrote: > On 2009-09-11, Sebastien Douche 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] 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 <>___ 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 wrote: > On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton wrote: >> On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen >> 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 2009-09-11, Sebastien Douche 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] structuring the zopetoolkit SVN layout/web presence
+1 Jim On Tue, Sep 15, 2009 at 3:57 AM, Martijn Faassen 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/ > > 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 )
[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/ 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 )
