[Zope3-dev] Re: 'layer' vs. 'type'
Gustavo Niemeyer wrote: Hello everyone, I was just implementing a ZCML statement for a view-related component which should also take in consideration request interfaces for adaptation. After reading the SimplifySkinning proposal form Philipp, I'm somewhat unsure about how to define the request type in the ZCML directive in a way similar to what developers would expect in standard directives. I've seen in the code base and also in Philipp's proposal that the renaming of 'layer' to 'type' isn't complete yet, so I'd like to ask: does it really make sense? Consider something like the following: browser:something type=.ISomeInterface / I read this as the type of something is ISomeInterface rather than something is used with ISomeInterface requests. Let's take a more concrete example: IMenuItemsDirective. It's one of the many directives with a 'layer' field. If renamed to 'type', wouldn't that clash with the concept of MenuItemTypes? With this in mind I propose to either keep this argument as 'layer', or use a term that better represent the relation with request types, answering the question type of what?. What do you think? I wasn't sure about the layer to type renaming myself. Plus, it would've been one of those janitorial changes that just weren't worth it. That's why I didn't do it. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: deprecation of zope.app.introspector
On Thursday 14 September 2006 06:32, Florent Xicluna wrote: Philipp von Weitershausen philipp at weitershausen.de writes: We should remove it from the trunk. OK +1 For backward compatibility, I suggest we redefine zope.app.introspector.Introspect to zope.app.apidoc.UseAPIDoc via meta:redefinePermission. Good point. I did not know this directive. Here is the new patch, tested. Super. Looks good. Please add a BBB comment to the definition and reassignment of the old permission, like: !-- BBB: Will go away on 09/16/2007 -- Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Default zope.conf DB setup
Christian Theune wrote: Gah. Mea culpa. Until recently I didn't know that the zope.conf.in could even be copied over to zope.conf, because every checkout that I ever used always picked up the zope.conf and nothing ever told me to copy it. (Although I was slightly annoyed having to edit zope.conf.ing). I'll check whether anyone reverted the changes yet, otherwise, I'll clean that up. I'm 97.65% sure they haven't been reverted yet. (Luckily this only affects the checkouts, not the releases.) On the other hand, I'd like to know whether I'm the only one who stumbled over this, or if other people didn't know about copying zope.conf.in before (Some people assume it's trivially obvious that if it's named zope.conf.in then you know you have to copy it.) *If* someone else had that problem too, I'd propose to change away from the fallback of using zope.conf.in (we force people to create the principals too, don't we?) Right. I wouldn't mind that. +0 from me. At gocept we historically had similar features in projects, but we never fell back to using the '.in' version of a file but forced developers to copy it. I can't remember any case where this ended up in accidential checkins. Sorry again, Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Default zope.conf DB setup
On Saturday 16 September 2006 05:10, Philipp von Weitershausen wrote: *If* someone else had that problem too, I'd propose to change away from the fallback of using zope.conf.in (we force people to create the principals too, don't we?) Right. I wouldn't mind that. +0 from me. It is all about being quick to get started. I like that; so -1 from me, but I do not feel strongly about the issue. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Default zope.conf DB setup
Stephan Richter wrote: On Saturday 16 September 2006 05:10, Philipp von Weitershausen wrote: *If* someone else had that problem too, I'd propose to change away from the fallback of using zope.conf.in (we force people to create the principals too, don't we?) Right. I wouldn't mind that. +0 from me. It is all about being quick to get started. I like that; so -1 from me, but I do not feel strongly about the issue. We could automate it in the make process. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Default zope.conf DB setup
Philipp von Weitershausen wrote: Stephan Richter wrote: On Saturday 16 September 2006 05:10, Philipp von Weitershausen wrote: *If* someone else had that problem too, I'd propose to change away from the fallback of using zope.conf.in (we force people to create the principals too, don't we?) Right. I wouldn't mind that. +0 from me. It is all about being quick to get started. I like that; so -1 from me, but I do not feel strongly about the issue. We could automate it in the make process. That's true. Additionally we currently keep zope.conf.in and zopeskel/etc/zope.conf.in I guess we could get rid of the first one and ... wait. Maybe even better would be to just create an instance in-place? Are there any more .in-things around that are endangered by accidental edits? -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Release management refinements
On Wednesday 13 September 2006 13:28, Philipp von Weitershausen wrote: Contributing to a community also means adapting to its processes and way of working. The process has been working well for Zope 2 developers, so I don't see why it can't work for Zope 3. A couple of comments: First, if several -- as in a majority of -- people say I work this way W., then our process should be adapted to those people. Having those people contribute less, because of an unnecessary barrier. Second, Zope 2 and 3 are *very* different in this respect. Zope 2 does not have the same testing story. In Zope 2 it was risky, if not impossible, to use the trunk, because those large frameworks (CMF, Plone, ...) that had very tight couplings with Zope 2 had to be adjusted in many cases. Zope 3 is different, since the trunk is effectively as stable as any release at any time, especially now with the even stricter trunk policies and the desire to move packages out of the core. This allows developers to develop against the trunk. And even if the trunk is shaken by deprecation warnings like your refactorings, most packages based on Zope 3 were updated within a week, even large projects like SchoolTool and Tiks. This is a very strong statement and warrants a different check-in policy. To get into an even more fundamental discussion, I claim that the culture of test-driven development weakens some common software-engineering practices, such as release cycles. I think, and seeing our discussions it seems I am right, that releases are marketing tools, not important software engineering artifacts. Releases allow us to say, Here are those great new features., write a magazine article, be slashdotted, and tell the client we are already in version 3.X where X 100. Don't get me wrong, I understand the motivations behind releases, besides those points. It allows other developers to have a set target and something to rely on, etc. Thus I said, it weakens the release artifact, not obsolete it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Release management refinements
Stephan Richter wrote: On Wednesday 13 September 2006 13:28, Philipp von Weitershausen wrote: Contributing to a community also means adapting to its processes and way of working. The process has been working well for Zope 2 developers, so I don't see why it can't work for Zope 3. A couple of comments: First, if several -- as in a majority of -- people say I work this way W., then our process should be adapted to those people. Having those people contribute less, because of an unnecessary barrier. Agreed. But we'll have to make compromises between the comfort for the developers and the necessary house keeping that we inevitably have to commit ourselves to as a serious software project. The latter invariably includes maintaining old releases. Frankly, I personally don't feel very strongly where you commit a fix first, as long as the fix gets into all the necessary places. All I know is that the described way of working a) ensures that you don't forget to backport the fix b) works for many people I'm also strongly wondering whether the majority of the people actually do develop against the trunk. Second, Zope 2 and 3 are *very* different in this respect. Zope 2 does not have the same testing story. In Zope 2 it was risky, if not impossible, to use the trunk, because those large frameworks (CMF, Plone, ...) that had very tight couplings with Zope 2 had to be adjusted in many cases. Sorry, but when was the last time you contributed to Zope 2? You're using the past tense which is applicable to most of this. Zope 2 *does* have a testing story now. We can't make the past go away, but we have the same standard in terms of testing as Zope 3 does now. (And as far as the cutting-edge Plonistas are concerned, for example, they often do develop against the trunk or at least the latest development release branch). Plus, I don't see the point in the testing argument. Just because the Zope 3 trunk can be considered more stable (for some definition of stable) doesn't mean we can neglect stable releases branches. Zope 3 is different, since the trunk is effectively as stable as any release at any time, especially now with the even stricter trunk policies and the desire to move packages out of the core. This allows developers to develop against the trunk. I never said that that was a bad idea. And even if the trunk is shaken by deprecation warnings like your refactorings, most packages based on Zope 3 were updated within a week, even large projects like SchoolTool and Tiks. This is a very strong statement and warrants a different check-in policy. I disagree. I think the majority of those who do web development with Zope3 nowadays use releases. Gocept seems to do it, I do it, and most zope3-users@zope.org people seem to do it as well. Zope 3 isn't all about the trunk is our playground anymore. Again, I have nothing against development against the trunk, but thinking that this is the standard development model is mistaken. To get into an even more fundamental discussion, I claim that the culture of test-driven development weakens some common software-engineering practices, such as release cycles. I think, and seeing our discussions it seems I am right, that releases are marketing tools, not important software engineering artifacts. Releases allow us to say, Here are those great new features., write a magazine article, be slashdotted, and tell the client we are already in version 3.X where X 100. Don't get me wrong, I understand the motivations behind releases, besides those points. It allows other developers to have a set target and something to rely on, etc. Thus I said, it weakens the release artifact, not obsolete it. I think the most important fact about releases, strictly speaking from a software development view, is that they're milestones in terms of feature stability. We promise not to introduce new features and not to shake up things within a stable release branch. People want this sort of stability insurance (with the additional bugfix promise). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Release management refinements
--On 13. September 2006 20:12:50 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote at 2006-9-13 11:05 +0200: Over the last couple of days we've been discussing Zope's new release cycle and the release management. I would like to sum up what seems to be the gist of those discussions: 9 month release period? --- I am almost convinced that we will make the same experience as the Plone people: when we strive for a 9 month release cycle, we will get a 12 month cycle... I think this is almost a law for software development: completing in time is the exception not the rule. That's not the point here. We are discussing about the release periods in order to do not flood the community with new versions but not about the reasons why we are often running behind our schedule...that's a different issue :-) Andreas pgpluNfeu86yX.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
