Re: [Zope-dev] new zope.schema and zope.configuration releases
On Wed, Jan 6, 2010 at 8:39 AM, Chris McDonough wrote: > FYI, I just made two new releases: > > zope.schema 3.6.1 > zope.configuration 3.7.1 > > These releases provide basic compatibility with Jython. Congrats! this is great step towards supporting other Python implementations. I suggest everyone who release ZTK packages send a notification mail to zope-dev list. Regards, Baiju M ___ 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 best to intercept a request to send a 304 response in Zope 2
Laurence Rowe wrote: > 2009/12/31 Martin Aspeli: >> Hi, >> >> A few of us are playing with some caching tools, trying to get to a more >> sane and less monkey patch-laden approach than CacheFu >> (Products.CacheSetup), for use with Zope 2.12. >> >> It is relatively easy to set response headers, e.g. in an >> IPubBeforeCommit event handler. >> >> However, we also need to be able to intercept a request to send a 304 >> response if the underlying object has not been modified. >> >> CacheFu monkey patches ZPT rendering to avoid the actual rendering if a >> 304 response is being sent, returning an empty string instead. I'd >> rather not have such patches, though, and anyway this only work with >> things rendered as ZPTs. It also doesn't avoid any pre-work that a view >> may do before rendering its template, if indeed it has one. >> >> Another thought was to use IPubAfterTraversal, at which point we have >> the object to publish and security checks have been completed. However, >> ZPublisher.Publish goes straight from that into mapply(). >> >> Can anyone think of a good way to do this? Maybe we need to add some >> kind of condition around mapply(), e.g. to do not nothing if there's a >> 304 response header, or some other marker? > > I think this is analogous to 404 Not Found errors. It should be > possible to handle them with the combination of: > >* raise a NotModified exception in an IPubAfterTraversal handler >* in a NotModified exception view, setStatus 304 Not Modified an > return an empty string. Yep, I actually got there in the end on my own. The way that the exception *type/class name* is used to determine the status is pretty evil, but so long as the exception is actually called NotModified, it works. Setting it explicitly doesn't, since it gets overridden. See plone.caching's hooks.py for an implementation. I also had to tell Plone's error_log (in plone.app.caching's setuphandlers.py) not to log the exception, since zpublisher_error_hook always logs the exception even if there's a view on it. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] new zope.schema and zope.configuration releases
FYI, I just made two new releases: zope.schema 3.6.1 zope.configuration 3.7.1 These releases provide basic compatibility with Jython. - C ___ 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] New Zope 3 name: BlueBream
Hi All, Thanks to all those who participated in this discussion so far. I will try to make baby steps for the project. So, for time being I will focus on the getting started story (which is somewhat ready) then documentation, a small website ( http://bluebream.zope.org ) and before 1.0 release, an upgradation path from Zope 3.4 KGS. I am fine with calling the project as "Bream" for short, however "BlueBream" will remain. But all the framework specific packages will remain in "zope" and "zope.app" namespaces. May be we can think about "bream" as a namespace in future. I remember the days when I started contributing to Zope project. Zope developers were eagerly started looking at the larger Python community with cool technologies emerging out of it like WSGI, egg, Paste and other web frameworks. As a first step for adoption, eggification of Zope 3 packages was in radar for many contributors. I am glad that I was able to accelerate the project by creating a proposal: https://mail.zope.org/pipermail/zope3-dev/2006-October/020858.html To further accelerate the eggification of "zope.app" packages, I implemented Jim Fulton's proposal: https://mail.zope.org/pipermail/zope3-dev/2006-December/021352.html (BTW, This is the greatest appraisal I ever received from a FOSS community) With all the contributors effort, Zope 3 packages became more reusable by other projects. But the "Zope 3" users were at a loss, they lost their main development discussion platform itself (zope3-dev list) and there was no releases. Then Stephan Richter created Zope 3.4 KGS, that was a good move which helped the existense. For a sucessfull web framework, few packages maintained by people with different interest in not sufficient. With "BlueBream"/"Bream", I hope we will be able to bring together the "framework" developer community again. I appreciate all your support for this project. Regards, Baiju M ___ 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 best to intercept a request to send a 304 response in Zope 2
2009/12/31 Martin Aspeli : > Hi, > > A few of us are playing with some caching tools, trying to get to a more > sane and less monkey patch-laden approach than CacheFu > (Products.CacheSetup), for use with Zope 2.12. > > It is relatively easy to set response headers, e.g. in an > IPubBeforeCommit event handler. > > However, we also need to be able to intercept a request to send a 304 > response if the underlying object has not been modified. > > CacheFu monkey patches ZPT rendering to avoid the actual rendering if a > 304 response is being sent, returning an empty string instead. I'd > rather not have such patches, though, and anyway this only work with > things rendered as ZPTs. It also doesn't avoid any pre-work that a view > may do before rendering its template, if indeed it has one. > > Another thought was to use IPubAfterTraversal, at which point we have > the object to publish and security checks have been completed. However, > ZPublisher.Publish goes straight from that into mapply(). > > Can anyone think of a good way to do this? Maybe we need to add some > kind of condition around mapply(), e.g. to do not nothing if there's a > 304 response header, or some other marker? I think this is analogous to 404 Not Found errors. It should be possible to handle them with the combination of: * raise a NotModified exception in an IPubAfterTraversal handler * in a NotModified exception view, setStatus 304 Not Modified an return an empty string. 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] SVN: five.pt/trunk/ Fixed a calling convention oddity.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malthe Borch wrote: > Log message for revision 107710: > Fixed a calling convention oddity. > > Changed: > U five.pt/trunk/CHANGES.txt > U five.pt/trunk/src/five/pt/patches.py > > -=- > Modified: five.pt/trunk/src/five/pt/patches.py > === > --- five.pt/trunk/src/five/pt/patches.py 2010-01-05 15:50:46 UTC (rev > 107709) > +++ five.pt/trunk/src/five/pt/patches.py 2010-01-05 16:32:23 UTC (rev > 107710) > @@ -26,7 +26,7 @@ > except ImportError: > from zope.app.pagetemplate.viewpagetemplatefile import BoundPageTemplate > import Acquisition > - > + > class BoundPageTemplate(BoundPageTemplate, Acquisition.Implicit): > """Implementing Acquisition.interfaces.IAcquirer and > IAcquisitionWrapper. > @@ -34,9 +34,9 @@ > > __parent__ = property(lambda self: self.im_self) > > -def __call__(self, *args, **kw): > +def __call__(self, im_self=None, *args, **kw): > if self.im_self is None: > -im_self, args = args[0], args[1:] > +im_self = im_self > else: > im_self = aq_base(self.im_self) > if IAcquirer.providedBy(im_self): That can't be right: the if clause is a no-op. And no test for the case which was broken? 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD3igACgkQ+gerLs4ltQ7TZACeMO8fPNvRL10ySynw2ALSP9KF dpkAni7rXfeg6Xg+FzK1c+kPNpj1RkGN =n5Zm -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] SVN: Zope/branches/2.12/ Fixed possible TypeError while sending multipart emails.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Maurits van Rees wrote: >> Log message for revision 107689: >> Fixed possible TypeError while sending multipart emails. > >> Changed: >> U Zope/branches/2.12/doc/CHANGES.rst >> U Zope/branches/2.12/src/Products/MailHost/MailHost.py >> U Zope/branches/2.12/src/Products/MailHost/tests/testMailHost.py > > > > Is this fix already on the trunk? My bad -- I see that you forward-ported it later in the afternoon in r107723. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD3yoACgkQ+gerLs4ltQ5zFQCglsggi9GOM554z5MxQB4UnVPW sBIAn2WY0/TDiugL8QnqsJbBErc+6C3S =xzQI -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] SVN: Zope/branches/2.12/ Fixed possible TypeError while sending multipart emails.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maurits van Rees wrote: > Log message for revision 107689: > Fixed possible TypeError while sending multipart emails. > > Changed: > U Zope/branches/2.12/doc/CHANGES.rst > U Zope/branches/2.12/src/Products/MailHost/MailHost.py > U Zope/branches/2.12/src/Products/MailHost/tests/testMailHost.py Is this fix already on the trunk? 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD3VkACgkQ+gerLs4ltQ72+gCgrCjbpo5s6gAHG3EFXvwGfnuD vO4AoMQKbAyIoz8YG3LAgy6T78Z1AaG0 =WV5M -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.publisher 3.12 broke 25 zope.app packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > 25 zope.app packages are broken due to changes in zope.publisher 3.12. > zope.publisher had some components factored out of it into zope.login. > > I fixed zope.app.exception: it could be fixed by adding the zope.login > requirement and adding a zcml include statement. I suspect most, > probably all, other failures are similarly shallow. > > The breaking of so many packages wasn't noticed by anyone, until tests > of svn checkouts that previously worked now broke. > > I hope we can put mechanisms in place so that developers of ZTK packages > can be better made aware of breaking other packages that depend on the > ZTK. This way the developer making the changes could do one or more of > the following: > > * provide better backward compatibility > > * fix up the breaking packages > > * provide a better warning to others who are maintaining these packages > that something was broken. > > I faintly, faintly recall we had such early-warning mechanisms in the > past. :) AFAIK, the zope-tests list is the watchman on the battlements: seeing something break in its daily summary mail is usually the first warning I have that a checkin broke something. I would be glad to see other configurations sending their test results to that list, so that everybody gets notified about breakage. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD2X8ACgkQ+gerLs4ltQ4GOgCgqY4rrDVeio/TWp+/mzYWf4tH 1V4An0PeTUvwXOE7H0ii9HFbeyQa2AO7 =tkPS -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.security dependency on zope.exceptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabio Tranchitella wrote: > Happy New Year to everybody, > > I'm working to isolate a core set of ZTK packages which are independent > from Zope and reusable outside the Zope community. One of them is > zope.security, which can be used (and it is useful, indeed) with non-zope > frameworks too. > > While doing it, I'm trying to remove dependencies which are zope-specific, > to minimize the overhead for developers who are using the whole zope stack > (like me :)). I have such a subset in mind myself, which I call the "bicycle seat repair kit": - zope.interface - zope.coponent - zope.configuration - their dependencies. > zope.security depends on zope.exceptions because it imports this symbol in > zope.security.checker: > > from zope.exceptions import DuplicationError > > zope.exceptions defines DuplicationError as: > > class IDuplicationError(Interface): > pass > > class DuplicationError(Exception): > """A duplicate registration was attempted""" > implements(IDuplicationError) > > The zope.exceptions package contains "exception interfaces and > implementations which are so general purpose that they don't belong in Zope > application-specific packages.", as stated by the README. > > I propose to make the remove the dependency between zope.security and > zope.exceptions with a conditional import: > > * if zope.exceptions is available, use DuplicationError from it; > > * if it is not available, define a zope.security-specific DuplicationError >(which inherits from ValueError, maybe). > > As using zope.exceptions only make sense if you are checking the exception > type importing its interface from the zope.exceptions package, and thus > depending on it, I see no risk in such a change. > > Thoughts? Comments? +1. I wouldn't have thought zope.security useful elsewhere, but I take it you are using it in applications which don't use the rest of the stack. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD2N8ACgkQ+gerLs4ltQ7G0wCfVu0KZAZ5xzUXarXUO2nT6bIm LXQAoIYxT6lKDGgGeCq/ec7Xh+X+4WBo =dErh -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] New Zope 3 name: BlueBream
Martin Aspeli wrote: > Baiju M wrote: >> On Mon, Jan 4, 2010 at 11:53 PM, Baiju M wrote: >>> Hi All, >>> I am proposing to call "Zope 3 - the web frame work" >>> as "BlueBream". >> I am unable to make a conclusion out of this discussion as many >> real users of "Zope 3 - the web frame work" is not given +1 >> But there are so many +1 from other framework users like >> Grok,Zope 2,BFG etc. > > This may reflect the number of "pure Zope 3" users still active in the > community, although I'm speculating. > > What I would say, is that we shouldn't discount the votes from people > predominantly associated with Zope 2 or Grok. Those people still have a > stake in Zope, and are still hurt by the "Zope 3 is not a successor to > Zope 2" problem and the "Grok doesn't run on Zope 3, it runs on ZTK > (soon)" problem causing confusion for its users. > > I think we've known for years that Zope 3 has been difficult to market > and identify. For the first time in years, we have an opportunity to > have a much clearer story to the outside world. "Zope 2" is the thing > people have used for a decade and love to love or love to hate. There is > a package of useful web development tools known as the Zope Toolkit, or > ZTK for short. Blue Bream (which will inevitably be shortened to just > "Bream" but I think keeping the longer name is worthwhile) is a > full-stack framework also built on the ZTK. Grok is another full-stack > framework built on the ZTK, with a different emphasis on convention over > configuration. You could diagram the relationship between these things > relatively easily. > > I know we've had one -1 vote on the concept of renaming, and one -1 vote > on the name itself. I'd like to hear from Jim, the Launchpad crew, and > certainly give people some time. But as it stands, even "pure Zope 3" > people are in favour, with you and Stephan +1. > > I think what could happen is this: > >- You keep experimenting with a "quickstart" setup using Paste Script. > You should use the name "Blue Bream" there exclusively, or maybe just > "Bream" for short/internal things like package names. > >- In the meantime, we see if more opinions emerge. This isn't a > decision we should make in two days. > Grrr Cmd+Enter :) To continue: - The ZTK will hopefully stabilise on a "small" ZTK and a bigger ZopeApp KGS. - Get together with Marius, Stephan and anyone else who cares, and see if you can get a Blue Bream KGS that builds on the ZTK and uses the ZopeApp KGS. You probably want to depend on the ZTK and fork ZopeApp, since ZopeApp is just a transitional thing. In the longer run, Blue Bream is going to be the main owner of those things, and can choose which of those packages live or die. - Before you release anything, build bluebream.zope.org, a small and focused website explaining what Blue Bream is, its heritage, and its connection to Zope and the ZTK. Speak to Andreas, who has infrastructure for this kind of thing. - Create/document an upgrade path from "pure Zope 3" of old to Blue Bream. If you get to *that* point, and no-one's shot you down too much, release the whole thing and then try to maintain it. Congratulations, you are now the owner of a next-generation Python framework, built on the power of the ZTK. :) As an aside: I would *not* rename the zope.app.* namespace. Even new Blue Bream-only things can live in zope.app.*. This is the only way to keep a sane upgrade process for people with live Zope 3 applications, who are going to be your biggest audience. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] shrinking the ZTK: a proposed solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > You don't seem to get what I kept telling you over and over. I'm > therefore going to be more blunt. > > I don't want to use zope.app packages in Grok. Grok wants to get rid of > zope.app packages. That's the very idea. We pushed this from the start. > I spent a huge amount of time to make this possible, just like everyone > else. But Grok isn't there yet. Neither are people who have to maintain > Zope 3 apps. Sure, I hear you on that. > But I have to use zope.app packages in Grok 1.1, because people need to > have a way to move off zope.app in a working system. It will be the > equivalent, I believe, of Zope 2.12, though the details are different. > We cannot ask users to switch their imports in Grok 1.0, as there, for > instance, zope.app.container is the only thing that exists. There is no > zope.container yet to switch your imports to. And the versions.cfg maintained on the Grok trunk reflects that, right? I believe (without verification) that the list of zope.app packages there is actually bigger than what Grok needs in and of itself at this point. > I am not asking you to help me maintain zope.app packages until the end > of time. I'm asking you to help me support backwards compatibility code > in zope.app for a while longer, until I and others have transitioned > away from those packages as well. I'm not going to put proactive effort into maintaining those packages. I will be glad to help other developers who run into such issues diagnose them, and work out reasonable solutions for them, largely through discussions on this list. > If that code goes untested, it breaks. It already started breaking. > Jan-Wijbrand noticed test failures on zope.app.exception, just checking > it out from svn.zope.org. He didn't know a zope.publisher 3.12 was > released that created this breakage. He didn't even pin down the ZTK or > anything; it was just a checkout using the most recent releases. The > person who makes the change in the original package is likely able to > identify the cause for such breakage much more easily, and either warn > people about what to do, or make a quick fix himself. Getting the buildbots to be nearly-always-green, and then whine when anything goes red, is the only way I know of to ensure that such breakage will be detected and reesolved quickly. If I commit a change to a non-zope.app package which causes a zope.app-dependent build to go red, then I certainly expect to help the developers responsible for the package set of the red build figure out out to fix it. Unless they bring the issue up, however, I'm gonna remain blissfully ignorant. > So I'm using zope.app packages, and changes happen in the zope.* subset, > and zope.app packages are now breaking in SVN when buildouts are run. > > Until recently Zope 2 used zope.app packages too, for backwards > compatibility reasons. If the situation had been reversed and Grok had > been off zope.app first, I don't think you would have been very happy if > suddenly these started breaking as they became unmaintained. It used a subset of them which were *not* kept up to date with the ZTK. Please see the versions.cfg on the Zope 2.12 branch, and compare with the ZTK trunk: http://svn.zope.org/Zope/branches/2.12/versions.cfg?rev=107345 http://svn.zope.org/*checkout*/zopetoolkit/trunk/ztk.cfg?rev=107719 In effect, none of the "KGS" provided by the ZTK has been in use by ZOpe2 for a long while: one of the reasons I cheered Hanno's work was that it finally got Zope2 to use the ZTK *directly*, rather than via a fork. > Zope 2 is able to move off it more easily for a variety of reasons. Now > that you're done, but we aren't yet, I am hearing a loud "screw you, > we're done, we don't care about you anymore" from you. Please don't put words in my mouth. > That really pisses me off. > > It's also just plain stupid if you only a little bit enlightened in your > self-interest and want the ZTK to succeed and people outside the Zope 2 > community to use it. You're making that a lot harder. You're making my > lots life harder for short-term selfish reasons. And it makes me really > want to say "screw you too". But that would not be very enlightened. I want the ZTK to succeed: indeed, I have been working to position it such that it might be useful even outside the bounds of the current Zope community: I think that moving the zope.app packages out of the ZTK proper is the best possible thing we can do to move it towards success. I don't see how I'm making your life harder here: the zopeapp spinoff you created gives folks who still need a managed set of those packages a place to stand, while at the same time removing the burden of their maintenance from the toolkit. I never said that I wouldn't listen to feedback from consumers of zopeapp who discovered a problem introduced by a change in the ZTK. In fact, I have said repeatedly that
Re: [Zope-dev] New Zope 3 name: BlueBream
Baiju M wrote: > On Mon, Jan 4, 2010 at 11:53 PM, Baiju M wrote: >> Hi All, >> I am proposing to call "Zope 3 - the web frame work" >> as "BlueBream". > > I am unable to make a conclusion out of this discussion as many > real users of "Zope 3 - the web frame work" is not given +1 > But there are so many +1 from other framework users like > Grok,Zope 2,BFG etc. This may reflect the number of "pure Zope 3" users still active in the community, although I'm speculating. What I would say, is that we shouldn't discount the votes from people predominantly associated with Zope 2 or Grok. Those people still have a stake in Zope, and are still hurt by the "Zope 3 is not a successor to Zope 2" problem and the "Grok doesn't run on Zope 3, it runs on ZTK (soon)" problem causing confusion for its users. I think we've known for years that Zope 3 has been difficult to market and identify. For the first time in years, we have an opportunity to have a much clearer story to the outside world. "Zope 2" is the thing people have used for a decade and love to love or love to hate. There is a package of useful web development tools known as the Zope Toolkit, or ZTK for short. Blue Bream (which will inevitably be shortened to just "Bream" but I think keeping the longer name is worthwhile) is a full-stack framework also built on the ZTK. Grok is another full-stack framework built on the ZTK, with a different emphasis on convention over configuration. You could diagram the relationship between these things relatively easily. I know we've had one -1 vote on the concept of renaming, and one -1 vote on the name itself. I'd like to hear from Jim, the Launchpad crew, and certainly give people some time. But as it stands, even "pure Zope 3" people are in favour, with you and Stephan +1. I think what could happen is this: - You keep experimenting with a "quickstart" setup using Paste Script. You should use the name "Blue Bream" there exclusively, or maybe just "Bream" for short/internal things like package names. - In the meantime, we see if more opinions emerge. This isn't a decision we should make in two days. - If you're happy that your Blue Bream quickstart thing actually works, get together with Marius and Stephan and -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] shrinking the ZTK: a proposed solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey Tres, > > > Tres Seaver wrote: > >> You're kidding, right? > [snip] >> My self-interest? Not really: you are appealing to my altruism, in the >> fact that I care about the *broader* Zope community (broader than Zope2, >> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >> rely any longer on any of thsoe pacakages at all, which makes my direct >> interest in them exactly zero. > > Basically we all worked together for a year. Now Zope 2 happens to be > done first moving off zope.app, so you're telling me f$%#%Q#k you, I > don't need you anymore, go away. I don't mean to say anything like that: my contention is that the non-zope.app ZTK packages no longer have any dependencies on zope.app, which removes the only technical reason to keep them in the toolkit. A lot of the drive for that cleanup is the efforts from the Zope2 side to track down and eradicate those dependencies, because the Zope2 developers have had an explicit "zope.app delenda est"-geddon running for months now. I don't mean to shaft folks who are still depending on some subset of the zope.app packages: I'm just puzzled by the notion that they belong in the ZTK for any reason other than the ZTK's own internal testing dependencies, or that keeping them there helps anybody. Until last week, Up through the 2.12 release line, Zope2 has been happily consuming a non-ZTK subset of those packages (different pins than the ZTK trunk in some cases). Grok has a similar fork / subset in its own versions.cfg: figuring out which of the packages listed there are actual requirements for Grok is not a task I can devote any time to, but should be on the "front burner" for the Grok developers who are thinking about transitioning to the ZTK. I do think your zopeapp solution may have some appeal for various framework developers trying to transition to the pared-down ZTK, but I don't have any plans to devote any proactive bandwidth to that effort (as opposed to answering questions or helping resolve issues raised by people who are working with it). 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD0OsACgkQ+gerLs4ltQ7c6wCePZ0QpgU2Xp4riu9YdIg6yjka 3bIAoKjaj6RwsYjp770z1bj2kWeMSsi7 =iFqa -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] shrinking the ZTK: a proposed solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hermann Himmelbauer wrote: >> Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: >>> Hermann Himmelbauer wrote: But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK. >>> This is a surprise to me. I thought we still supported Python 2.4 >> That's a surprise to me, too: I remember endless discussions about dropping >> support for Python 2.4 on this list, let me see: >> >> https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html >> >> I thought the outcome was somehow that Python 2.4 support was dropped? > > I recall the conclusion was not to do that yet. Mailman says that you argued[1] for keeping 2.4 compatibility only for zope.interface and zope.component. I argued for keeping it for the whole "bicycle-seat toolkit"[2]. >> But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with >> Python 2.4 for the ZTK? > > I think we have a buildbot for it. > > http://dev.thehealthagency.com/buildbot/waterfall > > But I do see that Python 2.4 has a failed test, so we do need to fix that. Which job? There are a bunch of red ones, as well as a bunch of offlines. A waterfall which doesn't stay green most of the time is not very helpful. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktDxJ8ACgkQ+gerLs4ltQ6NEwCg3RNgOSmtziM5KRveDjL2dp37 yywAn2gjkzFNSb1abrJJQSwUo0UJ0qda =+B2p -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] New Zope 3 name: BlueBream
I like Bream. BlueBream or Blue Bream. Just change the name Zope3 so we get over it eventually. I'm a "zope3" user btw ! 2010/1/5 Lennart Regebro : > On Tue, Jan 5, 2010 at 16:55, Gediminas Paulauskas wrote: >> If we released "Zope 3 the web framework" as version 3.5, little would >> change for existing Zope 3 users since it still includes all zope.app >> packages with backward compatibility imports. Wasn't this the plan >> last year? I see no more confusion than was before, only less. The >> reasons mentioned here are now false, because Zope 3.5 is based on >> ZTK, Zope 2.12 is based on ZTK, and Grok is based on ZTK. Explanations >> written at http://download.zope.org/zope3.4/ are still true, and after >> renaming some occurrences of "Zope 3" to ZTK, Zope 3.5 KGS would be >> the same "Zope 3" thing as Zope 3.4 was. > > Absolutely. But the confusion between Zope 3 and Zope 2 persists. > Renaming Zope 3 in to "Bream" or "Blue Bream" or "BlueBream" (see > there, a good reason for just "Bream") gets rid of that confusion. I > don't think corporate people in general has a problem with renaming. > Renaming would also partly circumvent the "Oh no zope" reaction that > you *still* get from Python people, and which is almost exclusively > based on the unpythonishness of Zope 2. > > I'm not a Zope 3 developer, so I explicitly do not vote, as I don't > think I should have a say. :-) But I think a renaming would be > benefinial. > > But in the end this is yet another "non-decision". It is up to > whoever makes a Zope 3.5 KGS. If, for example, Baiju and Stephan > decides they want to do that, and they decide they want to call it > "Bream", then Bream it is. If say, Jan and Gediminas makes a 3.5 KGS, > and they don't want to rename it, then it will still be called "Zope". > In fact, it's perfectly possible to do both, but that *would* be > confusing as then Bream in fact would become a Zope 3 fork, not a new > name for Zope 3, so that would probably be less than ideal. > > There is also the absolute possibility that no 3.5 KGS ever happens, > in which case this discussion is moot. > > So: Talk less, do more. ;-) > > -- > Lennart Regebro: Python, Zope, Plone, Grok > http://regebro.wordpress.com/ > +33 661 58 14 64 > ___ > 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 ) > ___ 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] New Zope 3 name: BlueBream
On Tue, Jan 5, 2010 at 16:55, Gediminas Paulauskas wrote: > If we released "Zope 3 the web framework" as version 3.5, little would > change for existing Zope 3 users since it still includes all zope.app > packages with backward compatibility imports. Wasn't this the plan > last year? I see no more confusion than was before, only less. The > reasons mentioned here are now false, because Zope 3.5 is based on > ZTK, Zope 2.12 is based on ZTK, and Grok is based on ZTK. Explanations > written at http://download.zope.org/zope3.4/ are still true, and after > renaming some occurrences of "Zope 3" to ZTK, Zope 3.5 KGS would be > the same "Zope 3" thing as Zope 3.4 was. Absolutely. But the confusion between Zope 3 and Zope 2 persists. Renaming Zope 3 in to "Bream" or "Blue Bream" or "BlueBream" (see there, a good reason for just "Bream") gets rid of that confusion. I don't think corporate people in general has a problem with renaming. Renaming would also partly circumvent the "Oh no zope" reaction that you *still* get from Python people, and which is almost exclusively based on the unpythonishness of Zope 2. I'm not a Zope 3 developer, so I explicitly do not vote, as I don't think I should have a say. :-) But I think a renaming would be benefinial. But in the end this is yet another "non-decision". It is up to whoever makes a Zope 3.5 KGS. If, for example, Baiju and Stephan decides they want to do that, and they decide they want to call it "Bream", then Bream it is. If say, Jan and Gediminas makes a 3.5 KGS, and they don't want to rename it, then it will still be called "Zope". In fact, it's perfectly possible to do both, but that *would* be confusing as then Bream in fact would become a Zope 3 fork, not a new name for Zope 3, so that would probably be less than ideal. There is also the absolute possibility that no 3.5 KGS ever happens, in which case this discussion is moot. So: Talk less, do more. ;-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] New Zope 3 name: BlueBream
On Mon, Jan 4, 2010 at 11:53 PM, Baiju M wrote: > Hi All, > I am proposing to call "Zope 3 - the web frame work" > as "BlueBream". I am unable to make a conclusion out of this discussion as many real users of "Zope 3 - the web frame work" is not given +1 But there are so many +1 from other framework users like Grok,Zope 2,BFG etc. So, for time being I will keep the scope of "bluebream" - the package I created just as a PasteScript template. I will add minimum documentation about it's usage. If we reach any consensus, we can pick it up again. Regards, Baiju M ___ 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] shrinking the ZTK: a proposed solution
Jim Fulton wrote: > - When we refactor zope.app.foo to be zope.foo (or something else), > rather than changing >zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible. One problem with this is that if you have interfaces for which there are components registered, this can make it impossible to support both packages. For example, zope.app.container had IObjectAddedEvent. This is now in zope.lifecycleevent (it spent some time in zope.container, too, I think). If I have a system where some packages use the "new" zope.lifecycleevent and fire events from there, and I have an event handler registered for zope.app.container.interfaces.IObjectAddedEvent, that won't get called, unless zope.app.container.interfaces.IObjectAddedEvent is a compatibility import for zope.lifecycleevent.IObjectAddedEvent. This happened in Plone, by the way, when people started using things like z3c.form. So we certainly appreciated people changing zope.app.* in tandem with the refactoring. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] New Zope 3 name: BlueBream
2010/1/5 Martin Aspeli : > Andreas Jung wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Baiju M wrote: >>> Hi All, I am proposing to call "Zope 3 - the web frame work" as >>> "BlueBream". The main use for name is documentation. But the >>> package named "bluebream" will not provide any part of framework >>> code by itself. All the framework code will be in "zope" and >>> "zope.app" namespaces. >> I associate blueberry bagels with cream cheese when reading the name >> "Bluebream". Sorry but this name is pointless and does not solve any issue >> - - it just introduces some more confusion. > > I think if there are people interested in "the web development framework > previously known as Zope 3" - and it seem that there is - we'll need to > call it something. I think continuing to call it "Zope 3" is just > confusing, given that we've factored the ZTK out of Zope 3, and we've > spent ages saying that "Zope 3 is part of Zope 2" and "Zope 3 is part of > Grok". That message was confusing before, and the history since is > making it more confusing still. If we released "Zope 3 the web framework" as version 3.5, little would change for existing Zope 3 users since it still includes all zope.app packages with backward compatibility imports. Wasn't this the plan last year? I see no more confusion than was before, only less. The reasons mentioned here are now false, because Zope 3.5 is based on ZTK, Zope 2.12 is based on ZTK, and Grok is based on ZTK. Explanations written at http://download.zope.org/zope3.4/ are still true, and after renaming some occurrences of "Zope 3" to ZTK, Zope 3.5 KGS would be the same "Zope 3" thing as Zope 3.4 was. I am a Zope 3 developer for two large apps but I don't care about the fish. -- Gediminas Paulauskas Programmer at POV ___ 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] shrinking the ZTK: a proposed solution
On Sun, Jan 3, 2010 at 3:51 PM, Martijn Faassen wrote: > Hi there, > > So here's my proposed solution for the ZTK shrinking issue: > > The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since > Zope 2 forked the ZTK in response and continued to make changes to their > fork, I've tried to keep it in sync with the Zope 2 fork. > > I've created a new 'zopeapp' package that expands the ZTK with zope.app. > packages in my sandbox. This extracts that information from the ZTK. > > Hopefully after we get some feedback from other steering group members > (very silent indeed in the holiday period when all this happened) we can > make these two projects the official one: a ZTK project and a zopeapp > project. > > A few things I ask the ZTK maintainers: > > I ask the ZTK maintainers to have the same concern for the zope.app > packages as for any other user of the ZTK: work to support zopeapp's > compatibility with the ZTK. If the zopeapp maintainers have issues, > listen to them seriously. I think everybody can agree that this is > within the ZTK mandate for the time being, as zopeapp clearly exists and > is being used by a significant amount of people. (I'd like to work to > retire it by making it used by far less people) > > I also strongly encourage the ZTK maintainers to consider the situation > of backwards compatibility seriously. Help people transition from their > code now to the ZTK. Helping everybody migrate to the ZTK smoothly > increases the value of the ZTK itself. Obviously I cannot *force* ZTK > maintainers to worry about this. Instead I'm appealing to your > self-interest. And of course the transition burden is shared and should > not fall solely or even predominantly on the ZTK maintainers. > > I also think we as ZTK maintainers should better consider the concerns > of other users of the ZTK. In this case, Zope 2 had less of a concern > for zope.app than Grok or Zope 3. I didn't even understand this until > the debate was further along. The concerns of others should be > considered as well instead of simply rejected. We usually can find ways > to balance the concerns of everybody. To that end concerns (or lack > thereof) should be clearly communicated and be listened to. Big +1 from me. I'd especially like to encourage emphasis on backward compatibility. This is key for us. Some specific advice: - When we refactor zope.app.foo to be zope.foo (or something else), rather than changing zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible. - When we "clean up" and existing package without creating a new one in a way that is backward incompatible, let's update the major version number. 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] New Zope 3 name: BlueBream
On Tue, Jan 5, 2010 at 9:29 AM, Stephan Richter < srich...@cosmos.phy.tufts.edu> wrote: > On Monday 04 January 2010, Baiju M wrote: > > I am proposing to call "Zope 3 - the web frame work" > > as "BlueBream". The main use for name is documentation. > > But the package named "bluebream" will not provide > > any part of framework code by itself. All the framework > > code will be in "zope" and "zope.app" namespaces. > > I like the name too. As Simon suggested, a shorter "Bream" might be better. > There is too much blue in technology already.. > +1 on just "bream" from an interested bystander. Somehow the "blue" makes me think of microsoft. And "bream" is really easy to type on a qwerty keyboard but my fingers trip badly on "bluebream". That l-u-e-b-r-e sequence is hard. -Ethan ___ 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] shrinking the ZTK: a proposed solution
Am Dienstag 05 Januar 2010 16:18:17 schrieb Andreas Jung: > Lennart Regebro wrote: > > On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer > > > > wrote: > >> Hmmm. Bad luck for me. > > > > It would be interesting to know why you have to use Python 2.4. > > Dropping Python 2.4 support asap for any module is basically a good thing. > I encountered lately a serve issue within large unicode string in > Python 2.4. > The Python developers rejected the issue with wont-fix since Python > 2.4 is no longer > maintained...it's time to move on... Basically I agree. But in my case, it's quite hard to move on - at least for now... Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] shrinking the ZTK: a proposed solution
Am Dienstag 05 Januar 2010 16:12:02 schrieb Lennart Regebro: > On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer wrote: > > Hmmm. Bad luck for me. > > It would be interesting to know why you have to use Python 2.4. My application relies on the MaxDB database (former SAP-DB). They offer a Python module which can only be imported with Python <= 2.4. I still hope that SAP releases a newer Python module, although they don't seem to do so soon. So the remaining alternative is to develop a DBAPI 2.0 compliant Python/MaxDB module by myself, which is, however, quite some work. Another alternative would be to switch over to PostgreSQL, but this is not yet possible. Btw., if you are interested, you can see the application here (an online banking for training firms): http://zis.act.at/bankneu/s/start Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] shrinking the ZTK: a proposed solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer > wrote: >> Hmmm. Bad luck for me. > > It would be interesting to know why you have to use Python 2.4. Dropping Python 2.4 support asap for any module is basically a good thing. I encountered lately a serve issue within large unicode string in Python 2.4. The Python developers rejected the issue with wont-fix since Python 2.4 is no longer maintained...it's time to move on... Andreas - -- ZOPYX Limited \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, i...@zopyx.com \ www.zopyxgroup.com - E-Publishing, Python, Zope & Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktDWDkACgkQCJIWIbr9KYwOIwCfQVZfYFjHI6T1AyjtqyNpd5kQ VnUAoLLJu/z28JMuewQfD+2IjV+r6cKF =vmng -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] shrinking the ZTK: a proposed solution
On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer wrote: > Hmmm. Bad luck for me. It would be interesting to know why you have to use Python 2.4. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] shrinking the ZTK: a proposed solution
Am Dienstag 05 Januar 2010 16:05:34 schrieb Laurence Rowe: > 2010/1/5 Hermann Himmelbauer : > > Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen: > >> Hermann Himmelbauer wrote: > >> > Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: > >> >> Hermann Himmelbauer wrote: > >> >>> But I have to further state that I'm locked into Zope 3.4.0 as the > >> >>> support for Python 2.4 was dropped, so I can't upgrade to the > >> >>> current ZTK. > >> >> > >> >> This is a surprise to me. I thought we still supported Python 2.4 > >> > > >> > That's a surprise to me, too: I remember endless discussions about > >> > dropping support for Python 2.4 on this list, let me see: > >> > > >> > https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html > >> > > >> > I thought the outcome was somehow that Python 2.4 support was dropped? > >> > >> I recall the conclusion was not to do that yet. > > > > That's good news for me - don't know why I assumed that. > > Note that ZODB is dropping python 2.4 support in 3.10. > https://mail.zope.org/pipermail/zodb-dev/2009-December/013084.html Hmmm. Bad luck for me. Thanks for the Info. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] shrinking the ZTK: a proposed solution
2010/1/5 Hermann Himmelbauer : > Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen: >> Hermann Himmelbauer wrote: >> > Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: >> >> Hermann Himmelbauer wrote: >> >>> But I have to further state that I'm locked into Zope 3.4.0 as the >> >>> support for Python 2.4 was dropped, so I can't upgrade to the current >> >>> ZTK. >> >> >> >> This is a surprise to me. I thought we still supported Python 2.4 >> > >> > That's a surprise to me, too: I remember endless discussions about >> > dropping support for Python 2.4 on this list, let me see: >> > >> > https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html >> > >> > I thought the outcome was somehow that Python 2.4 support was dropped? >> >> I recall the conclusion was not to do that yet. > > That's good news for me - don't know why I assumed that. Note that ZODB is dropping python 2.4 support in 3.10. https://mail.zope.org/pipermail/zodb-dev/2009-December/013084.html 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] shrinking the ZTK: a proposed solution
Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen: > Hermann Himmelbauer wrote: > > Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: > >> Hermann Himmelbauer wrote: > >>> But I have to further state that I'm locked into Zope 3.4.0 as the > >>> support for Python 2.4 was dropped, so I can't upgrade to the current > >>> ZTK. > >> > >> This is a surprise to me. I thought we still supported Python 2.4 > > > > That's a surprise to me, too: I remember endless discussions about > > dropping support for Python 2.4 on this list, let me see: > > > > https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html > > > > I thought the outcome was somehow that Python 2.4 support was dropped? > > I recall the conclusion was not to do that yet. That's good news for me - don't know why I assumed that. What I currently don't understand is what the suggested upgrade path from KGS 3.4 is: Should I simply use the current packages from the SVN, hence drop the "versions=versions" directive from buildout.cfg? Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] shrinking the ZTK: a proposed solution
On Sunday 03 January 2010, Martijn Faassen wrote: > So here's my proposed solution for the ZTK shrinking issue: I really like the proposed solution of the small ZTK and an addon zope.app superset. It provides me with an example how to create other supersets. And I do agree that a migration path and some longer-term support is very, very important. 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] shrinking the ZTK: a proposed solution
Jens Vagelpohl wrote: > How is that any different from people who won't use the ZTK because they > don't want to deal with any zope.app* baggage? We have a proposal for dealing with that now: To maintain two KGS', one for ZTK and one for ZopeApp. We can and should run tests for both, and ensure that ZopeApp depends on the appropriate ZTK release. This way, if a ZTK package is changed in a way that breaks ZopeApp, at least we'll know. We have a number of people who have a stake in ZopeApp and are willing to help maintain it. We also have a history of people maintaining libraries caring about their consumers. You are the poster child for that, I think, being immensely helpful with CMF releases for the purposes of Plone. I don't see this being any different. I think everyone agrees that: - zope.app.* is not very interesting to anyone other than possibly a subset being useful in Zope3/BlueBream/wahteveritgetscalled. - We clearly had people using "some subset of Zope 3" for ages, long before the ZTK concept existed. - Ergo, we have a *lot* of zope.app.* imports in the wild. - We tried to arrive at a common subset we could collectively maintain to make all our lives easier and called that ZTK. - We agree that ZTK should not have zope.app.* packages in it, or indeed other "less useful" zope.* packages. - We have a number of frameworks trying to move towards using the ZTK. - Those frameworks are in various states of completion towards that goal. - The shape of the ZTK itself is influenced by that process of dependency untangling that allows frameworks to move towards adopting it. Thus we have a two-way process of changes flowing between the ZTK itself and the various consumers or would-be consumers. This was evidenced when Hanno removed zope.app.* packages from the ZTK. That helped the ZTK towards it end goal, but it also caused pain for people whose frameworks are less advanced in that goal and may need zope.app.* for a while longer. - Waking up one morning to find your buildout going crazy and having to backtrack in svn to find out what the KGS used to be and piecing it together is not nice. - There's benefit in having a tested set of zope.app.* packages and testing that against the ZTK, so that when ZTK developers break a zope.app.* package *that is currently used by someone*, they can at least be aware of that. - This situation may go away in the near-to-mid-term future when (a) the major frameworks have managed to get a release out that uses the ZTK proper without zope.app.* and/or (b) someone decides to actually love some subset of zope.app.*. That "someone" is likely BlueBream or whatever. So, in short: - No-one wants zope.app.* in the ZTK. - zope.app.* exists in the wild today, in real projects, for real users, who we are going to ask to upgrade to some ZTK supported release of their framework soon. - Some people were disadvantaged when it disappeared over night and need a bit more time/help to get there. - Most/all people would like us to try to work together for mutual benefit. The proposal to have a ZopeApp KGS with a buildbot and a dependency on ZTK is perfectly reasonable. In the worst case scenario, those self-styled ZTK maintainers who don't want to ever see zope.app.* again will have a little bit of guilt because they broke other people's code. In the best case, we'll work together to fix those breakages, or identify that no-one cares about a particular zope.app.* and kill it from ZopeApp forever. Somehow, we all lost our cool at around the same time. Let's stop the non-factual discussions and think about what people actually *need* to get their jobs done, and find out who has interest and capacity to support that. And please, let's stop making this an "everyone vs. Martijn" debate, because apart from a few lapses in style, he's actually making a lot of sense and speaking for real people with real needs. I'll count myself as one of them to shut up any debate about whether such people really exist. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] New Zope 3 name: BlueBream
On Monday 04 January 2010, Baiju M wrote: > I am proposing to call "Zope 3 - the web frame work" > as "BlueBream". The main use for name is documentation. > But the package named "bluebream" will not provide > any part of framework code by itself. All the framework > code will be in "zope" and "zope.app" namespaces. I like the name too. As Simon suggested, a shorter "Bream" might be better. There is too much blue in technology already.. 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] shrinking the ZTK: a proposed solution
Martijn Faassen wrote: > Hey Tres, > > > Tres Seaver wrote: > >> You're kidding, right? > [snip] >> My self-interest? Not really: you are appealing to my altruism, in the >> fact that I care about the *broader* Zope community (broader than Zope2, >> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >> rely any longer on any of thsoe pacakages at all, which makes my direct >> interest in them exactly zero. > > Basically we all worked together for a year. Now Zope 2 happens to be > done first moving off zope.app, so you're telling me f$%#%Q#k you, I > don't need you anymore, go away. In a strange twist of fate, I find myself agreeing with your position and disagreeing with your style. Take a deep breath, Martijn. People may argue passionately, but they're not doing anything like what you imply with punctuation, and this type of escalation is very counter-productive. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] shrinking the ZTK: a proposed solution
Martijn Faassen wrote: [snip] > But I do see that Python 2.4 has a failed test, so we do need to fix that. Some of those failure appears to be because some code was switched over to the Python standard library pprint from the version in zope.testing, and in Python 2.4 that doesn't sort dictionaries. http://dev.thehealthagency.com/buildbot/builders/ztk%20slave-ubuntu32-py2.4/builds/4/steps/test/logs/stdio We already talked about undeprecating that pprint function in zope.testing.doctestunit. It'd be nice if someone looked into doing that. 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] shrinking the ZTK: a proposed solution
Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martijn Faassen wrote: >> Hey Tres, >> >> >> Tres Seaver wrote: >> >>> You're kidding, right? >> [snip] >>> My self-interest? Not really: you are appealing to my altruism, in the >>> fact that I care about the *broader* Zope community (broader than Zope2, >>> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >>> rely any longer on any of thsoe pacakages at all, which makes my direct >>> interest in them exactly zero. >> Basically we all worked together for a year. Now Zope 2 happens to be >> done first moving off zope.app, so you're telling me f$%#%Q#k you, I >> don't need you anymore, go away. > > That's not what he is telling you. I don't think he ever intentionally > "worked together" to support zope.app* packages in any way. If anything, > he may have had input into and interest in the "small ZTK" packages > and/or direction, so his viewpoint has never changed. Well, Zope 2 released with a smaller but present dependency on zope.app some time ago. Those zope.app packages were at least until then relevant to Zope 2 developers. If support for them had been dropped by someone then, they would have had to pick up maintaining them themselves, if they wanted to continue tracking the ZTK and give Zope 2 users an upgrade path out of zope.app. Whether they are still relevant today is harder to say as Zope 2 already had some transition time behind it. 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] shrinking the ZTK: a proposed solution
Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hermann Himmelbauer wrote: >> Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver: >>> Martijn Faassen wrote: Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers. >>> My self-interest? Not really: you are appealing to my altruism, in the >>> fact that I care about the *broader* Zope community (broader than Zope2, >>> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >>> rely any longer on any of thsoe pacakages at all, which makes my direct >>> interest in them exactly zero. >> If the ZTK is decoupled from other users, e.g. from people who rely on >> zope.app, then they will simply not use it, or do a fork. >> >> This way, ZTK users are lost, which also leads to a loss of supporters and >> developers and results in a shrinking interest in ZTK, whose primary goal >> was/is to be _the_ base for all other Zope-based applications. > > How is that any different from people who won't use the ZTK because they > don't want to deal with any zope.app* baggage? We were all together carrying the old zope.app* baggage for reasons of transitioning out of it. Then one of the party managed to transition out of it first. So without warning, they dropped the baggage and ran away as fast as they could. :) 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] shrinking the ZTK: a proposed solution
Hermann Himmelbauer wrote: > Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: >> Hermann Himmelbauer wrote: >>> But I have to further state that I'm locked into Zope 3.4.0 as the >>> support for Python 2.4 was dropped, so I can't upgrade to the current >>> ZTK. >> This is a surprise to me. I thought we still supported Python 2.4 > > That's a surprise to me, too: I remember endless discussions about dropping > support for Python 2.4 on this list, let me see: > > https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html > > I thought the outcome was somehow that Python 2.4 support was dropped? I recall the conclusion was not to do that yet. > But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with > Python 2.4 for the ZTK? I think we have a buildbot for it. http://dev.thehealthagency.com/buildbot/waterfall But I do see that Python 2.4 has a failed test, so we do need to fix that. 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] shrinking the ZTK: a proposed solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hermann Himmelbauer wrote: > Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver: >> Martijn Faassen wrote: >>> Obviously I cannot *force* ZTK >>> maintainers to worry about this. Instead I'm appealing to your >>> self-interest. And of course the transition burden is shared and should >>> not fall solely or even predominantly on the ZTK maintainers. >> My self-interest? Not really: you are appealing to my altruism, in the >> fact that I care about the *broader* Zope community (broader than Zope2, >> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >> rely any longer on any of thsoe pacakages at all, which makes my direct >> interest in them exactly zero. > > If the ZTK is decoupled from other users, e.g. from people who rely on > zope.app, then they will simply not use it, or do a fork. > > This way, ZTK users are lost, which also leads to a loss of supporters and > developers and results in a shrinking interest in ZTK, whose primary goal > was/is to be _the_ base for all other Zope-based applications. How is that any different from people who won't use the ZTK because they don't want to deal with any zope.app* baggage? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktDOoMACgkQRAx5nvEhZLJKSwCgiQc3RIgtiDrL+CPib5mMr0WM /aoAoKNl0YZCL7B78Q8fp53xn8UecQF5 =X5h+ -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] shrinking the ZTK: a proposed solution
Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver: > Martijn Faassen wrote: > > Obviously I cannot *force* ZTK > > maintainers to worry about this. Instead I'm appealing to your > > self-interest. And of course the transition burden is shared and should > > not fall solely or even predominantly on the ZTK maintainers. > > My self-interest? Not really: you are appealing to my altruism, in the > fact that I care about the *broader* Zope community (broader than Zope2, > Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) > rely any longer on any of thsoe pacakages at all, which makes my direct > interest in them exactly zero. If the ZTK is decoupled from other users, e.g. from people who rely on zope.app, then they will simply not use it, or do a fork. This way, ZTK users are lost, which also leads to a loss of supporters and developers and results in a shrinking interest in ZTK, whose primary goal was/is to be _the_ base for all other Zope-based applications. So I think, being altruistic may be quite the same as acting out of self-interest. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] shrinking the ZTK: a proposed solution
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: > Hermann Himmelbauer wrote: > > But I have to further state that I'm locked into Zope 3.4.0 as the > > support for Python 2.4 was dropped, so I can't upgrade to the current > > ZTK. > > This is a surprise to me. I thought we still supported Python 2.4 That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see: https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html I thought the outcome was somehow that Python 2.4 support was dropped? But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with Python 2.4 for the ZTK? Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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: 3 OK, 3 Unknown
Summary of messages to the zope-tests list. Period Mon Jan 4 12:00:00 2010 UTC to Tue Jan 5 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Unknown --- Subject: UNKNOWN : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 4 20:45:19 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013325.html Subject: UNKNOWN : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 4 20:47:19 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013326.html Subject: UNKNOWN : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 4 20:49:19 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013327.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Jan 4 20:41:19 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013323.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Jan 4 20:43:19 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013324.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 4 20:51:19 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013328.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] New Zope 3 name: BlueBream
On Tue, Jan 5, 2010 at 11:28, Andreas Jung wrote: > I associate blueberry bagels with cream cheese when reading the name > "Bluebream". Yummy! -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] shrinking the ZTK: a proposed solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey Tres, > > > Tres Seaver wrote: > >> You're kidding, right? > [snip] >> My self-interest? Not really: you are appealing to my altruism, in the >> fact that I care about the *broader* Zope community (broader than Zope2, >> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >> rely any longer on any of thsoe pacakages at all, which makes my direct >> interest in them exactly zero. > > Basically we all worked together for a year. Now Zope 2 happens to be > done first moving off zope.app, so you're telling me f$%#%Q#k you, I > don't need you anymore, go away. That's not what he is telling you. I don't think he ever intentionally "worked together" to support zope.app* packages in any way. If anything, he may have had input into and interest in the "small ZTK" packages and/or direction, so his viewpoint has never changed. My own perspective on this issue is similar, with the difference that my list of chosen platforms is just Zope 2 at the moment. I'm also sharing his belief that we're having a serious disconnect between your expectation in regards to zope.app and how it should continue and our belief what the ZTK was and should be. However, none of this should lead to swearing. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktDIl4ACgkQRAx5nvEhZLJAPACeOje6/JQC9uKzPr/YknuZzyTw nCUAnili87j/qKjQu0EgdwnMZebLUd0u =SeE8 -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] shrinking the ZTK: a proposed solution
Hi Tres, You don't seem to get what I kept telling you over and over. I'm therefore going to be more blunt. I don't want to use zope.app packages in Grok. Grok wants to get rid of zope.app packages. That's the very idea. We pushed this from the start. I spent a huge amount of time to make this possible, just like everyone else. But Grok isn't there yet. Neither are people who have to maintain Zope 3 apps. But I have to use zope.app packages in Grok 1.1, because people need to have a way to move off zope.app in a working system. It will be the equivalent, I believe, of Zope 2.12, though the details are different. We cannot ask users to switch their imports in Grok 1.0, as there, for instance, zope.app.container is the only thing that exists. There is no zope.container yet to switch your imports to. I am not asking you to help me maintain zope.app packages until the end of time. I'm asking you to help me support backwards compatibility code in zope.app for a while longer, until I and others have transitioned away from those packages as well. If that code goes untested, it breaks. It already started breaking. Jan-Wijbrand noticed test failures on zope.app.exception, just checking it out from svn.zope.org. He didn't know a zope.publisher 3.12 was released that created this breakage. He didn't even pin down the ZTK or anything; it was just a checkout using the most recent releases. The person who makes the change in the original package is likely able to identify the cause for such breakage much more easily, and either warn people about what to do, or make a quick fix himself. So I'm using zope.app packages, and changes happen in the zope.* subset, and zope.app packages are now breaking in SVN when buildouts are run. Until recently Zope 2 used zope.app packages too, for backwards compatibility reasons. If the situation had been reversed and Grok had been off zope.app first, I don't think you would have been very happy if suddenly these started breaking as they became unmaintained. Zope 2 is able to move off it more easily for a variety of reasons. Now that you're done, but we aren't yet, I am hearing a loud "screw you, we're done, we don't care about you anymore" from you. That really pisses me off. It's also just plain stupid if you only a little bit enlightened in your self-interest and want the ZTK to succeed and people outside the Zope 2 community to use it. You're making that a lot harder. You're making my lots life harder for short-term selfish reasons. And it makes me really want to say "screw you too". But that would not be very enlightened. 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] shrinking the ZTK: a proposed solution
Hermann Himmelbauer wrote: > But I have to further state that I'm locked into Zope 3.4.0 as the support > for > Python 2.4 was dropped, so I can't upgrade to the current ZTK. This is a surprise to me. I thought we still supported Python 2.4 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] shrinking the ZTK: a proposed solution
Hey Tres, Tres Seaver wrote: > You're kidding, right? [snip] > My self-interest? Not really: you are appealing to my altruism, in the > fact that I care about the *broader* Zope community (broader than Zope2, > Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) > rely any longer on any of thsoe pacakages at all, which makes my direct > interest in them exactly zero. Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away. Thanks. 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] New Zope 3 name: BlueBream
robert rottermann wrote: [snip] > all the other items bear so little "market value" that even an insider can not > place them. > > Therefore I think either of the two should be part of any new packages name > meant to be recognized by non Zope affectionados. > > Bluebream for Zope I've sometimes called Grok "Zope Grok", but there's a value if establishing a new brand as well. Grok, Zope 2 and Blue Bream would all be unified as users of the Zope Toolkit. You can also do a lot with domain names to give a unified sense, we have grok.zope.org and we could also have docs.zope.org/bluebream or something like that. And with web page layouts. Anyway, the BlueBream documentation would certainly talk about Zope anyway. 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] Possible Zope 2.12 regression - Five page templates use restrictedTraverse for TAL
it took me hours to find out that i had the same issue in a plone-4.0a3 buildout until i found this thread in the meantime 2.12.2 is released so all one needs to do is to modify http://dist.plone.org/release/4.0a3/versions.cfg to use zope-2.12.2: [buildout] extends = http://download.zope.org/Zope2/index/2.12.2/versions.cfg ... Zope2 = 2.12.2 thanks for fixing this! fRiSi Martin Aspeli wrote: > On 15/12/09 5:45, Tres Seaver wrote: > >>> I've committed this in r106436 and merged to trunk in r106437. >> >> OK, sounds fine to me. Can you merge to the 2.11 branch as well? I >> think Andreas will be releasing 2.9.x through 2.12.x fairly soon. > > Sure, I'd forgotten about that one. > >>> If anyone objects, please let me know and I'll back it out. Otherwise, >>> I'm hopeful for a 2.12.2 soon, as this breaks a few things in Plone. :-/ >> >> Heh, and after you have been just posting about using SVN develop eggs >> on your blog. ;) > > Right. I can run from a develop egg in this project, but I wouldn't want > to ask everyone who uses Plone to do that. :) > > Martin > -- Webmeisterei GmbH - Büro für Netzfragen Tel: +43 5572 908877, Fax: +43 5572 908877-66 Steinebach 18, A-6850 Dornbirn http://www.webmeisterei.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] New Zope 3 name: BlueBream
Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Baiju M wrote: >> Hi All, I am proposing to call "Zope 3 - the web frame work" as >> "BlueBream". The main use for name is documentation. But the >> package named "bluebream" will not provide any part of framework >> code by itself. All the framework code will be in "zope" and >> "zope.app" namespaces. > I associate blueberry bagels with cream cheese when reading the name > "Bluebream". Sorry but this name is pointless and does not solve any issue > - - it just introduces some more confusion. I think if there are people interested in "the web development framework previously known as Zope 3" - and it seem that there is - we'll need to call it something. I think continuing to call it "Zope 3" is just confusing, given that we've factored the ZTK out of Zope 3, and we've spent ages saying that "Zope 3 is part of Zope 2" and "Zope 3 is part of Grok". That message was confusing before, and the history since is making it more confusing still. Blue Bream is as arbitrary as anything. I think the fact that it has some connection to Zope is kind of cute. It's also relatively Google-friendly, and pretty easy to remember. There are worse names, even if it makes you think about bagels and cheese. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] New Zope 3 name: BlueBream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: > Hi All, I am proposing to call "Zope 3 - the web frame work" as > "BlueBream". The main use for name is documentation. But the > package named "bluebream" will not provide any part of framework > code by itself. All the framework code will be in "zope" and > "zope.app" namespaces. I associate blueberry bagels with cream cheese when reading the name "Bluebream". Sorry but this name is pointless and does not solve any issue - - it just introduces some more confusion. Andreas - -- ZOPYX Limited \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, i...@zopyx.com \ www.zopyxgroup.com - E-Publishing, Python, Zope & Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktDFF0ACgkQCJIWIbr9KYzp/gCghnV0E9zzBWh+9v9npxpdecIv WkMAoJZ4HbHp5/RIldo8pv5YjD4a/rdb =6TbB -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] New Zope 3 name: BlueBream
Am 04.01.2010, 19:23 Uhr, schrieb Baiju M : > Hi All, > I am proposing to call "Zope 3 - the web frame work" > as "BlueBream". The main use for name is documentation. > But the package named "bluebream" will not provide > any part of framework code by itself. All the framework > code will be in "zope" and "zope.app" namespaces. - 1 even though I'm hardly a developer. Needed to check the date on this - but it's only January not April. I remember when Zope Magazine ran with the fish as its logo and it made little sense to me then even though it was explained. :-( Despite the number of votes in favour I do not understand the need for rebranding and especially not just for the documentation. Where has the discussion come from? Referring to the orginally extremely contrived name doesn't do it for me. But if a new name is required "Project Blue" or just plain "Blue" would be preferrable. Happy New Year to everyone! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 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 )
Re: [Zope-dev] New Zope 3 name: BlueBream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Jan Ulrich Hasecke wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 05.01.10 08:36, Martin Aspeli wrote: >>> +1. It puts the final nail in the Zope 3 coffin and allows a reborn >>> vampire to emerge from slumber. >> Ok, we all hate the damage that Zope 3 did and I have no problem to call >> one of the x Zope Webframeworks "Bluebream", but I would like to save >> the trademark from vanishing completely. >> >> What we have now are a bunch of Webframeworks built upon the ZTK. One of >> these frameworks is called Zope 2 for historical reasons. So if you tell >> the Zope story, you might end up with a story without a hero: > > Maybe we'll go back to the future, so the framework is Zope and the > version number is 2. :-) +1 Before Zope 3 Zope 1 and 2 were "Zope". I don't see why that should change. With the "devolution" of Zope 3 it is only logical to move the name "Zope" back to Zope 2. >> We have the ZTK in the center and some other peripheral libraries and we >> have Grok, Zope2, Bluebream, BFG, bobo and Humpty Dumpty, all great >> frameworks. We can even call them Zope Frameworks, but where is Zope in >> this story? What is Zope? Zope 2 is Zope. >> Possible solution: >> If all of the ZTK is in the namespace zope someday, why don't we call >> the ZTK "Zope", as it seems to be the heart of all these webframeworks? It is not at the heart of all those frameworks. The ZTK is used by some of them, to a varying degree. > The Z in ZTK stands for Zope. It's not useful "on its own", though, so > calling it just "Zope" would be confusing as hell. I fully agree. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktDBNQACgkQRAx5nvEhZLKWLACeKD4uO9Q3b95/RLfDN7Ux/cJM EdQAoLYWBoDZT5H0q2zkpffF5aQ9enYY =UWM9 -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] New Zope 3 name: BlueBream
Jan Ulrich Hasecke wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05.01.10 08:36, Martin Aspeli wrote: >> +1. It puts the final nail in the Zope 3 coffin and allows a reborn >> vampire to emerge from slumber. > > Ok, we all hate the damage that Zope 3 did and I have no problem to call > one of the x Zope Webframeworks "Bluebream", but I would like to save > the trademark from vanishing completely. > > What we have now are a bunch of Webframeworks built upon the ZTK. One of > these frameworks is called Zope 2 for historical reasons. So if you tell > the Zope story, you might end up with a story without a hero: Maybe we'll go back to the future, so the framework is Zope and the version number is 2. :-) > We have the ZTK in the center and some other peripheral libraries and we > have Grok, Zope2, Bluebream, BFG, bobo and Humpty Dumpty, all great > frameworks. We can even call them Zope Frameworks, but where is Zope in > this story? What is Zope? > > Possible solution: > If all of the ZTK is in the namespace zope someday, why don't we call > the ZTK "Zope", as it seems to be the heart of all these webframeworks? The Z in ZTK stands for Zope. It's not useful "on its own", though, so calling it just "Zope" would be confusing as hell. > Then we can tell a story where there are different cool webframeworks > based on Zope (former ZTK) which is a well defined set of libraries to > do component-based web-development. Please, let's not make anything "former ZTK". That name is just starting to stick. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] New Zope 3 name: BlueBream
Hi there, On 01/04/2010 07:23 PM, Baiju M wrote: > Hi All, > I am proposing to call "Zope 3 - the web frame work" > as "BlueBream". The main use for name is documentation. > But the package named "bluebream" will not provide > any part of framework code by itself. All the framework > code will be in "zope" and "zope.app" namespaces. > > BTW, the original meaning of "BlueBream" is > same as that of "Zope": > http://en.wikipedia.org/wiki/Abramis_ballerus Oh cool. +1 -- 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 ___ 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] New Zope 3 name: BlueBream
On Tue, Jan 5, 2010 at 09:16, Jan Ulrich Hasecke wrote: > Possible solution: > If all of the ZTK is in the namespace zope someday, why don't we call > the ZTK "Zope", as it seems to be the heart of all these webframeworks? If Zope 2 disappears, which still is at least years in the future, then I'd expect that people start calling The Zope Toolkit just "Zope" out of pure laziness. But that is still way ahead in a fuzzy future. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] New Zope 3 name: BlueBream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05.01.10 08:36, Martin Aspeli wrote: > +1. It puts the final nail in the Zope 3 coffin and allows a reborn > vampire to emerge from slumber. Ok, we all hate the damage that Zope 3 did and I have no problem to call one of the x Zope Webframeworks "Bluebream", but I would like to save the trademark from vanishing completely. What we have now are a bunch of Webframeworks built upon the ZTK. One of these frameworks is called Zope 2 for historical reasons. So if you tell the Zope story, you might end up with a story without a hero: We have the ZTK in the center and some other peripheral libraries and we have Grok, Zope2, Bluebream, BFG, bobo and Humpty Dumpty, all great frameworks. We can even call them Zope Frameworks, but where is Zope in this story? What is Zope? Possible solution: If all of the ZTK is in the namespace zope someday, why don't we call the ZTK "Zope", as it seems to be the heart of all these webframeworks? Then we can tell a story where there are different cool webframeworks based on Zope (former ZTK) which is a well defined set of libraries to do component-based web-development. juh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktC9VUACgkQPUzUEFbILMTiaACeKozFqtbZadk7qVRfKnoXvagY 6XUAnid2GsCtrOhkUL3SHmOK0rD6vplU =YT9A -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 )
