Re: [Zope-dev] my take on ZCML's includeOverrides
On Tue, 2010-12-07 at 14:27 -0500, Chris McDonough wrote: > > > [13:48] override is exactly the wrong phrase to use in the name > > > of this directive > > > [13:51] what it boils down to is that you never, ever really > > > want to use includeOverrides except in your rootmost zcml file > > > [13:51] and probably not even there > > > [13:51] because you can get the same effect by typing the > > > directives there by hand > > > > Why would you want to type the directives by hand? > > I *think* I'm of the opinion that libraries (or even "reusable > applications") probably shouldn't need to use includeOverrides. You > might disagree. I'd actually like to hear your take on that, because > I'm only about 90% confident about that. ;-) I realize that not every > application knows whether it's going to be reused or not, but, even so, > it's always an option to cutnpaste the topmost ZCML from that > application into a new file and disuse the old one. > > But if you take for granted the idea that libraries shouldn't use > "includeOverrides", the place that it is actually potentially useful is > in the "deployment" ZCML file (the topmost ZCML file that includes other > ZCML from libraries and other application packages). But in this > scenario, I already "own" the topmost ZCML file, and since it's > deployment-specific, there's no sense in breaking out the included stuff > into a separate file, because no one else will ever reuse it. It's all > deployment-specific policy. So, arguing with myself about that: [14:31] so i can see exactly one use case for includeOverrides so far [14:31] that's that you have an existing application which doesnt have its zcml nicely factored [14:31] and you're afraid (for whatever reason) to just cutpaste it into a new app [14:31] and you want to create a new package [14:32] that includes the other application's zcml then override bits of it [14:32] you could do that by doing [14:32] [14:32] [14:32] [14:32] or you could do [14:32] [14:33] [14:33] either would have exactly the same effect So yes, I see what you were getting at in your last mail. But I think we might be wise to draw some lines around this reuse-of-an-application pattern, at least conventionally. My take on application reuse is this: as soon as you've assumed control of top-level configuration via a "newapp" overrides package, you've more or less chosen to use "oldapp" as a library rather than as just-an-application (NB: oldapp and newapp are names I mention above in the example of includeOverride, representing an application that wants to be reused as "oldapp" and a package created by an overriding user as "newapp"). This sort of usage is a bit weird, because usually you depend on a plain-old-Python library to have a relatively stable API. But in the application-reuse example, often the original "oldapp" author has provided no such stability assurances with respect to how he uses ZCML. In such a case, you're always going to be depending on implementation details. When you punt to reusing oldapp's toplevel ZCML, it's because you don't want to track changes to oldapp, but you still want to get the benefit of being able to override some of its policy in newapp. I think this is pretty much impossible in general. Although your newapp overrides *may* continue to work across oldapp updates, if oldapp provided no promise of stability, you'll still need to track its changes. It would be much better if the oldapp author provided instructions about how to best reuse his application as a library. Those instructions probably wouldn't instruct customizers to reuse his top-level "example" ZCML configuration, but might imply reusing some other ZCML files that include configuration unlikely to need to be overridden. Or he might ship part of "oldapp" as a "true" library that has a bit of ZCML in it for reuse by integrators, but distribute another package that represents a deployable configuration of "oldapp" in a separate package. Or something. I dunno, hard topic. - 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] my take on ZCML's includeOverrides
On Tue, Dec 7, 2010 at 2:27 PM, Chris McDonough wrote: > On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: >> On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough wrote: >> > Independent of my previous call for discussion about ZCML conflict >> > resolution, I'm cutting and pasting my side of a discussion about the >> > ZCML "includeOverrides" directive from an IRC chat, because it may come >> > in useful for folks grappling with its behavior. There's not really any >> > human-consumable docs about it. >> > >> > If I've made any mistakes, please let me know. >> > >> > [13:42] so ftr, i've found that ZCML's includeOverrides and >> > include to do (at least on one vector) exactly the opposite of what you >> > might expect them to do >> > [13:42] "includeOverrides" is a poor name >> > [13:42] what it does is to emulate the behavior of inlining >> > stuff into the file you use it from >> > [13:43] when you use includeOverrides it's as if you typed all >> > the directives in the included file into the file you're including from >> > [13:43] otoh, "include" doesnt behave like this >> > [13:44] you can actually define the same directive in three >> > files >> > [13:44] configure.zcml, one.zcml, and two.zcml >> > [13:44] and if you use "include" from configure.zcml of one and >> > two >> > [13:44] there will be no conflict >> > [13:45] this is because non-conflicting "rootmost" directives >> > win >> > [13:45] otoh, if you use includeOverrides of one and two from >> > configure.zcml >> > [13:45] all three will conflict >> > [13:45] because its as if you typed them all in configure.zcml >> > by hand >> > [13:45] and that means there are three conflicting rootmost >> > directives >> > [13:46] if you mentally substitute "inline" for >> > "includeOverrides" it makes a little more sense >> >> Maybe. It described the mechanism better, but includeOverrides conveys the >> intent. > > Sorry, not a criticism, just a personal observation. No problem. Your observation is valid. > I assume I'm not wrong about the behavior I describe above? I don't think so. >> > [13:48] override is exactly the wrong phrase to use in the name >> > of this directive >> > [13:51] what it boils down to is that you never, ever really >> > want to use includeOverrides except in your rootmost zcml file >> > [13:51] and probably not even there >> > [13:51] because you can get the same effect by typing the >> > directives there by hand >> >> Why would you want to type the directives by hand? > > I *think* I'm of the opinion that libraries (or even "reusable > applications") probably shouldn't need to use includeOverrides. You > might disagree. I'd actually like to hear your take on that, because > I'm only about 90% confident about that. ;-) By now you've probably seen my other post where I said I think we've taken comparability too far. :) I should have noted there that I was talking about "configrability" in terms of selective overriding. If something is going to be configurable, by which I mean overridable, then I think includeOverrides or something like it is pretty valuable. > I realize that not every > application knows whether it's going to be reused or not, Not only that, YAGNI says it should be written from the start as if it isn't, until it is. :) or more importantly, it shouldn't be written to have it's parts overridden until a compelling reason has been found to do so. > but, even so, > it's always an option to cutnpaste the topmost ZCML from that > application into a new file and disuse the old one. Yeah, just like you can reuse Python code by copying it. It's usually better to reuse by reference if possible. > But if you take for granted the idea that libraries shouldn't use > "includeOverrides", Unless the library is built on some other library. Even then, include may be a better option, but there is still overriding going on. > the place that it is actually potentially useful is > in the "deployment" ZCML file (the topmost ZCML file that includes other > ZCML from libraries and other application packages). In practice, I haven't found this to be a single file, but that's probably beside the point. > But in this > scenario, I already "own" the topmost ZCML file, and since it's > deployment-specific, there's no sense in breaking out the included stuff > into a separate file, because no one else will ever reuse it. It's all > deployment-specific policy. This is like saying that a main program that uses libraries shouldn't be broken into subprograms. 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] my take on ZCML's includeOverrides
On 12/07/2010 12:27 PM, Chris McDonough wrote: > I *think* I'm of the opinion that libraries (or even "reusable > applications") probably shouldn't need to use includeOverrides. +1, I would be very suspicious of any library that uses includeOverrides. Any use of it ought to be highly visible to developers. Shane ___ 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] my take on ZCML's includeOverrides
On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: > On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough wrote: > > Independent of my previous call for discussion about ZCML conflict > > resolution, I'm cutting and pasting my side of a discussion about the > > ZCML "includeOverrides" directive from an IRC chat, because it may come > > in useful for folks grappling with its behavior. There's not really any > > human-consumable docs about it. > > > > If I've made any mistakes, please let me know. > > > > [13:42] so ftr, i've found that ZCML's includeOverrides and > > include to do (at least on one vector) exactly the opposite of what you > > might expect them to do > > [13:42] "includeOverrides" is a poor name > > [13:42] what it does is to emulate the behavior of inlining > > stuff into the file you use it from > > [13:43] when you use includeOverrides it's as if you typed all > > the directives in the included file into the file you're including from > > [13:43] otoh, "include" doesnt behave like this > > [13:44] you can actually define the same directive in three > > files > > [13:44] configure.zcml, one.zcml, and two.zcml > > [13:44] and if you use "include" from configure.zcml of one and > > two > > [13:44] there will be no conflict > > [13:45] this is because non-conflicting "rootmost" directives > > win > > [13:45] otoh, if you use includeOverrides of one and two from > > configure.zcml > > [13:45] all three will conflict > > [13:45] because its as if you typed them all in configure.zcml > > by hand > > [13:45] and that means there are three conflicting rootmost > > directives > > [13:46] if you mentally substitute "inline" for > > "includeOverrides" it makes a little more sense > > Maybe. It described the mechanism better, but includeOverrides conveys the > intent. Sorry, not a criticism, just a personal observation. I assume I'm not wrong about the behavior I describe above? > > [13:48] override is exactly the wrong phrase to use in the name > > of this directive > > [13:51] what it boils down to is that you never, ever really > > want to use includeOverrides except in your rootmost zcml file > > [13:51] and probably not even there > > [13:51] because you can get the same effect by typing the > > directives there by hand > > Why would you want to type the directives by hand? I *think* I'm of the opinion that libraries (or even "reusable applications") probably shouldn't need to use includeOverrides. You might disagree. I'd actually like to hear your take on that, because I'm only about 90% confident about that. ;-) I realize that not every application knows whether it's going to be reused or not, but, even so, it's always an option to cutnpaste the topmost ZCML from that application into a new file and disuse the old one. But if you take for granted the idea that libraries shouldn't use "includeOverrides", the place that it is actually potentially useful is in the "deployment" ZCML file (the topmost ZCML file that includes other ZCML from libraries and other application packages). But in this scenario, I already "own" the topmost ZCML file, and since it's deployment-specific, there's no sense in breaking out the included stuff into a separate file, because no one else will ever reuse it. It's all deployment-specific policy. > I've used includeOverrides in cases where: > > 1. I want to use 2 high-level components, one of which > customizes the other, or in which > > 2. I wanted to organize overrides in various ways where I > don't want to put everything in a root (or high-level file). > > Of course, you can sometimes get the same effect in other ways. > For example, if one high-level component overrides another, then > the overriding component can just include the overridden one. > > Jim > ___ 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] We work waaaaay to hard to make everything configurable (Re: ZCML conflict resolution)
On Tue, Dec 7, 2010 at 1:51 PM, Jim Fulton wrote: > On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough wrote: ... > A user wants to reuse a high-level component (aka package aka > "project" in distutils > jargon aka "product" in distutils jargon). They want to customize > the high-level component without hacking its code. BTW, we work way to hard to satisfy the second part of this goal. Yeah, somethings do want to be configurable. But we make things far more configurable than they need to be and we've paid a high price in complexity. The answer to this IMO isn't to make configuration easier, better, more automatic, or implicit, or whatever. (Let's just take the spoon out of the glass. :) 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] my take on ZCML's includeOverrides
On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough wrote: > Independent of my previous call for discussion about ZCML conflict > resolution, I'm cutting and pasting my side of a discussion about the > ZCML "includeOverrides" directive from an IRC chat, because it may come > in useful for folks grappling with its behavior. There's not really any > human-consumable docs about it. > > If I've made any mistakes, please let me know. > > [13:42] so ftr, i've found that ZCML's includeOverrides and > include to do (at least on one vector) exactly the opposite of what you > might expect them to do > [13:42] "includeOverrides" is a poor name > [13:42] what it does is to emulate the behavior of inlining > stuff into the file you use it from > [13:43] when you use includeOverrides it's as if you typed all > the directives in the included file into the file you're including from > [13:43] otoh, "include" doesnt behave like this > [13:44] you can actually define the same directive in three > files > [13:44] configure.zcml, one.zcml, and two.zcml > [13:44] and if you use "include" from configure.zcml of one and > two > [13:44] there will be no conflict > [13:45] this is because non-conflicting "rootmost" directives > win > [13:45] otoh, if you use includeOverrides of one and two from > configure.zcml > [13:45] all three will conflict > [13:45] because its as if you typed them all in configure.zcml > by hand > [13:45] and that means there are three conflicting rootmost > directives > [13:46] if you mentally substitute "inline" for > "includeOverrides" it makes a little more sense Maybe. It described the mechanism better, but includeOverrides conveys the intent. > [13:48] override is exactly the wrong phrase to use in the name > of this directive > [13:51] what it boils down to is that you never, ever really > want to use includeOverrides except in your rootmost zcml file > [13:51] and probably not even there > [13:51] because you can get the same effect by typing the > directives there by hand Why would you want to type the directives by hand? I've used includeOverrides in cases where: 1. I want to use 2 high-level components, one of which customizes the other, or in which 2. I wanted to organize overrides in various ways where I don't want to put everything in a root (or high-level file). Of course, you can sometimes get the same effect in other ways. For example, if one high-level component overrides another, then the overriding component can just include the overridden one. 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 )
[Zope-dev] my take on ZCML's includeOverrides
Independent of my previous call for discussion about ZCML conflict resolution, I'm cutting and pasting my side of a discussion about the ZCML "includeOverrides" directive from an IRC chat, because it may come in useful for folks grappling with its behavior. There's not really any human-consumable docs about it. If I've made any mistakes, please let me know. [13:42] so ftr, i've found that ZCML's includeOverrides and include to do (at least on one vector) exactly the opposite of what you might expect them to do [13:42] "includeOverrides" is a poor name [13:42] what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] when you use includeOverrides it's as if you typed all the directives in the included file into the file you're including from [13:43] otoh, "include" doesnt behave like this [13:44] you can actually define the same directive in three files [13:44] configure.zcml, one.zcml, and two.zcml [13:44] and if you use "include" from configure.zcml of one and two [13:44] there will be no conflict [13:45] this is because non-conflicting "rootmost" directives win [13:45] otoh, if you use includeOverrides of one and two from configure.zcml [13:45] all three will conflict [13:45] because its as if you typed them all in configure.zcml by hand [13:45] and that means there are three conflicting rootmost directives [13:46] if you mentally substitute "inline" for "includeOverrides" it makes a little more sense [13:48] override is exactly the wrong phrase to use in the name of this directive [13:51] what it boils down to is that you never, ever really want to use includeOverrides except in your rootmost zcml file [13:51] and probably not even there [13:51] because you can get the same effect by typing the directives there by hand - 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] ZCML conflict resolution
On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough wrote: > I'm trying to decide whether to repurpose the conflict detection in > zope.configuration for non-XML configuration. Cool. ... > Unfortunately, the documentation in the code tends to explains the > mechanics of conflict resolution, but not the intent. I'll take a guess > though: > > - the "rootmost" directive that participates in a conflict is meant to > "win". > > - if there is more than one "rootmost" directive that participates in a > conflict, the conflict cannot be resolved. > > Does my summary sound about right? Yes, but ... > Does anyone have any insight as to > why this particular conflict resolution strategy was chosen? I'm really > just trying to understand the intent. The intent was to provide a way of overriding configuration in a way that was unambiguous and understandable. (Of course, it fails in the case of subscribers, but I think that's beside your point. :) Let's take this up a level, to user goals. A user wants to reuse a high-level component (aka package aka "project" in distutils jargon aka "product" in distutils jargon). They want to customize the high-level component without hacking its code. *That* is really the intent. 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] Zope 2.13 and zope.publisher >= 3.9
On Tue, Dec 7, 2010 at 7:13 PM, Sylvain Viollon wrote: > That new option annoy me in Zope 2.13, as there is no such option to > the redirect method on the Zope 2 response. > > - changing the default value of the trusted option in zope.publisher, > to be a bit more backward compatible (and call that redirect with > trusted=False in zope.[app].authentication where it motivated that > change), We already adjusted all the ZTK code to work with this new default and released this over 18 months ago. I think it's too late to change the behavior again. > - add a trusted option to redirect in Zope 2. If adding a simple "trusted=None" no-op to the redirect method helps you, I wouldn't be opposed to it. I wouldn't even port the actual feature as it's not all too useful and the ZPublisher implements a lot of things differently compared to zope.publisher anyways. If you really want to port the feature, we need to make it backwards compatible in Zope 2, so by default all redirects should be allowed (default of trusted=True). Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCML conflict resolution
I'm trying to decide whether to repurpose the conflict detection in zope.configuration for non-XML configuration. zope.configuration has the following resolveConflicts function, which attempts to resolve action discriminator conflicts. def resolveConflicts(actions): """Resolve conflicting actions Given an actions list, identify and try to resolve conflicting actions. Actions conflict if they have the same non-null discriminator. Conflicting actions can be resolved if the include path of one of the actions is a prefix of the includepaths of the other conflicting actions and is unequal to the include paths in the other conflicting actions. ... """ The code in resolveConflicts indeed matches the docstring description. In the "test_simple.py" test file, a little more light is shed on conflict resolution: """Conflicting actions can be resolved if one of the conflicting actions is from a configuration file that directly or indirectly includes the files containing the other conflicting actions.""" There's also a test in test_xmlconfig.py that goes into details about includeOverrides and conflict detection. (Note that I don't care about includeOverrides here. I think I understand it, after some wrangling with it.) Unfortunately, the documentation in the code tends to explains the mechanics of conflict resolution, but not the intent. I'll take a guess though: - the "rootmost" directive that participates in a conflict is meant to "win". - if there is more than one "rootmost" directive that participates in a conflict, the conflict cannot be resolved. Does my summary sound about right? Does anyone have any insight as to why this particular conflict resolution strategy was chosen? I'm really just trying to understand the intent. - 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 )
[Zope-dev] Zope 2.13 and zope.publisher >= 3.9
Hello, In zope.publisher 3.9.0, the signature of the redirect method of a response changed to include a new trusted option that you *need* to set to True in order to get redirect working in most cases (otherwise it denies the redirect that are not in the domain than your application). That new option annoy me in Zope 2.13, as there is no such option to the redirect method on the Zope 2 response. Now I am working in five.grok which uses grokcore.view. Grokcore.view provides some redirect utilities, and they have to use that trusted option in order to get things working. And they doesn't work in Zope 2 anymore. So I would like a bit of help to fix that problem. I see two possible solutions: - changing the default value of the trusted option in zope.publisher, to be a bit more backward compatible (and call that redirect with trusted=False in zope.[app].authentication where it motivated that change), - add a trusted option to redirect in Zope 2. What do you thing what should be done ? (Yes, I will create a launchpad issue, but I would like to see that issue fixed more or less quickly). Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 94 OK, 4 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2010 06:58 AM, Zope Tests Summarizer wrote: > Test failures > - > > Subject: FAILED : Zope Buildbot / zopetoolkit-py2.7 slave-ubuntu64 > From: jdriessen at thehealthagency.com > Date: Mon Dec 6 13:58:00 EST 2010 > URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025802.html > > Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win > From: jdriessen at thehealthagency.com > Date: Mon Dec 6 14:19:13 EST 2010 > URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025808.html > > Subject: FAILED : Zope Buildbot / zopetoolkit-py2.7 slave-ubuntu32 > From: jdriessen at thehealthagency.com > Date: Mon Dec 6 14:25:59 EST 2010 > URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025810.html > > Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.5 slave-win > From: jdriessen at thehealthagency.com > Date: Mon Dec 6 14:31:11 EST 2010 > URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025814.html Interesting: both the ZTK + Python 2.5 + windows failures look like corrupted build environments (inability to import stuff which ought to be there). The ZTK + Python 2.7 + Ubuntu failures are tied into the non-weakref-ability of the security proxies. I filed a bug against Python 2.7 which should make this issue clearer (maybe even make it go away): http://bugs.python.org/issue10360 My patch is checked in for py3k, but is not yet merged to the 2.7 maintenance branch. ;) 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+RfgACgkQ+gerLs4ltQ5cxQCcCCFRo+V4sSpVmq4FCPMsREpP s0kAoI+lp30JPBg6Qe+ZNYw5os9sA9WH =tF4K -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 )
[Zope-dev] Zope Tests: 94 OK, 4 Failed
Summary of messages to the zope-tests list. Period Mon Dec 6 12:00:00 2010 UTC to Tue Dec 7 12:00:00 2010 UTC. There were 98 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 19 from buildbot at winbot.zope.org, 11 from ccomb at free.fr, 56 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zopetoolkit-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:58:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025802.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Mon Dec 6 14:19:13 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025808.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.7 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Dec 6 14:25:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025810.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Mon Dec 6 14:31:11 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025814.html Tests passed OK --- Subject: OK : Zope Buildbot / zope2.12-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:02:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025770.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:05:16 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025771.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:07:33 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025772.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:09:47 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025773.html Subject: OK : Zope Buildbot / zope2.14-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:12:02 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025774.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:20:58 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025775.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:29:58 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025776.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:39:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025777.html Subject: OK : Zope Buildbot / zopetoolkit-py2.5 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:44:40 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025778.html Subject: OK : Zope Buildbot / zopetoolkit-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:50:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025779.html Subject: OK : Zope Buildbot / zopetoolkit-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:56:23 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025780.html Subject: OK : Zope Buildbot / zope2.14-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:59:20 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025781.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 08:01:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025782.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 08:03:50 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025783.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 08:06:07 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025784.html Subject: OK : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:19:53 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025785.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:21:29 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025786.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:23:02 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025787.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 From: jdriessen at theh
