Re: [Zope-dev] Re: Hivurt code hosting
On Sunday 11 November 2007, Paul Winkler wrote: > Today 21:16:09 > > > On Sun, Nov 11, 2007 at 06:37:22PM -0500, Stephan Richter wrote: > > Yes, everyone has to sign a contributor agreement, but you do not have to > > become a Zope Foundation member. > > I had the impression, from the recent ZF IRC chat, that the process of > adding new contributors is currently blocked - but perhaps I > misunderstood? No, it blocks the move of the source to the ZF. You can still sign the non-ZF contributor agreement (version 1.1) and become a commiter today. I signed up several people a month ago during the Foliage Sprint. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Hivurt code hosting
On Sun, Nov 11, 2007 at 06:37:22PM -0500, Stephan Richter wrote: > Yes, everyone has to sign a contributor agreement, but you do not have to > become a Zope Foundation member. I had the impression, from the recent ZF IRC chat, that the process of adding new contributors is currently blocked - but perhaps I misunderstood? -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Duplicate directive registration allowed
On Wednesday 07 November 2007, Malthe Borch wrote: > So for instance, if Five registers the then there's > nothing to prevent another package from including zope.viewlet's > meta.zcml which will then override that directive, breaking viewlet > support on Zope 2.10. I agree with your analysis. Could you file a bug report in launchpad? Thanks, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Hivurt code hosting
I believe you can host code on launchpad.net too, but using 'bzr' instead of Subversion. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Hivurt code hosting
On Sunday 11 November 2007, Mikhail Kashkin wrote: > Jodok Batlogg wrote: > >> I'm looking for place to host our source code for Hivurt. > > > > svn.zope.org + launchpad.net as the rest of the zope world? > > That is mean that all our developers need signed contribution agreement > and writing rights to submit code into zope repository and be members of > Zope Foundation? I don't think every ZoFo member agree with this. Yes, everyone has to sign a contributor agreement, but you do not have to become a Zope Foundation member. Note that svn.zope.org will also provide you with a lot of visibility to the right people. You may also consider codespeak.net. > launchpad.net from other hand is best place, especially if zope3 is > hosted here. Note that we only use launchpad for development support, such as issue tracking and translating. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Sunday 11 November 2007, Jim Fulton wrote: > > This breaks a fundamental assumption for releases. When I release > > something, I expect it to work tomorrow, next month, and next year. > > If you want this, then you can't rely on the KGS. When releasing our > applications, we don't rely on a KGS. We fix all of the versions > we're using. IMO, the KGS shouldn't try to solve this problem. A > KGS should be helpful for developers and development frameworks. A > KGS will be more useful if the quality remains high. A KGS is > similar to a traditional monolithic release. After all, bug fix Zope > releases have been known to break applications too. I really hope you will use the KGS as a starting point somewhen for your internal applications as well. :-) (Note that you can now override versions using the new "extends" feature that I shamelessly copied from buildout.) And I am not saying this to promote the KGS. I have a concrete example. Probably as part of a project, Benji did some development on zope.testbrowser. He fixed the versions of all dependencies in buildout.cfg. However, those versions were a version sub-graph of a ZC internal dependency graph that I do not have access to. It was also already pretty outdated referring to "dev" and "alpha" releases. So while testbrowser might be working with those dependency versions, it might still be broken for me, because I have a totally different dependency graph. The worst scenario, which luckily has not happened yet, is that we fix things back and forth because of different dependency graphs. I thus propose that all packages in svn.zope.org should use a KGS for testing, because it is a fully public dependency graph. I am not sure whether it should be the latest stable KGS or the development KGS or whatever. Time will provide an answer. BTW, Benji wanted me to bring this issue up on the mailing list already, so I fulfilled my commitment now. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Nov 11, 2007, at 6:11 PM, Stephan Richter wrote: On Sunday 11 November 2007, Lennart Regebro wrote: On Nov 11, 2007 8:06 AM, Martijn Faassen <[EMAIL PROTECTED]> wrote: I therefore still believe that version dependency information should move out of external indexes and into packages. This is at least the intuitive place for this information. My application requires Grok 0.11, which requires zope 3.4.0b2 which then would be a package that doesn't contain any code, just requirements of eggs that in turn has requirements of their own. I'm not even sure this *is* different from how the unices does it, but it just seems the obvious way of doing it. I would be interested in knowing if this has drawbacks. Meta-eggs are considered a bad idea in the Python world. I originally wanted to create a meta-egg, but Jim convinced my to use a different approach; hence the index. Meta eggs aren't a bad or a good idea by themselves. They are a good solution to some problems and a bad (or less good) solution to others. IMO, meta eggs are a good way to fix versions in *applications*. (I think buildout's version-specification mechanism is another good approach, with certain advantages and disadvantages). I think a package repository, of which a KGS is an example, is a good way to provide access to a collection of packages known to work together -- especially as it provides a nice way to manage bug fixes. I think "Zope 3" is better served by a well-managed repository, because Zope 3 is a platform, not an application. IMO, a well-managed KGS (set of KGS releases) will serve the community of developers who use Zope better than a rigid version specification. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Sunday 11 November 2007, Lennart Regebro wrote: > On Nov 11, 2007 8:06 AM, Martijn Faassen <[EMAIL PROTECTED]> wrote: > > I therefore still believe that version dependency information should > > move out of external indexes and into packages. > > This is at least the intuitive place for this information. My > application requires Grok 0.11, which requires zope 3.4.0b2 which then > would be a package that doesn't contain any code, just requirements of > eggs that in turn has requirements of their own. I'm not even sure > this *is* different from how the unices does it, but it just seems the > obvious way of doing it. I would be interested in knowing if this has > drawbacks. Meta-eggs are considered a bad idea in the Python world. I originally wanted to create a meta-egg, but Jim convinced my to use a different approach; hence the index. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Sunday 11 November 2007, Martijn Faassen wrote: > What KGS solves is that it allows the ongoing development and testing of > an integrated Zope 3. That is, there's a Zope 3 'trunk' of versions > that keeps being updated as there are bugfix releases. I'm not sure what > happens as soon as someone wants to make a new feature release of any > package. Presumably they end up in KGS too. Absolutely not! Like Linux distributions, there will be a KGS for every Zope 3 release. I have already requested a new directory called "zope-dev" where new feature releases can be tested. > After all, we won't have a > single Zope 3.4 and then a single Zope 3.5 for which we can create a new > KGS. Yes, we will. Why do you think the current KGS is called "zope3.4"? If you want to have a different working set, then you are free to create one, but don't expect much support from the community when things are not working as expected. > We intend to let packages move at different feature-release speeds, > and we can't have a KGS for each package. You do not need to have a single KGS for every package. But believing that we can just randomly make new feature releases that work with the rest of the world is naive at best. We have seen already what happens, if everyone uses their own set of versions and packages. A development KGS will be used to test new feature releases. > What KGS doesn't have is history. Yes, it does. Why do you think I manage the "controlled-packages.cfg" file in SVN? And in SVN, I do not create branches and tags without a reason. > When I release an application or > framework and I used KGS to make sure that all my versions were correct, > it will work on the day of release. As soon as enough bugfix (or > feature) releases make it to KGS, something will inevitably break. We've > seen innocuous changes breaking code a lot of times, so we can't pretend > that never happens. It *will* happen. I agree. Have you read the discussion we had yesterday on the zope-dev mailing list? We discussed the problem and possible solutions already. Here are a couple of choices we have to avoid the problem: 1. During development I would recommend to use the index of the latest stable release; or if you are brave, you can use the development KGS. (Of course, you can also use the versions block of a particular release, though you will miss out on bug fixes, which I think is less optimal.) 2. Once release/deployment time comes around, you lock the versions. There is a wide range of possibilities: (a) You download the "version.cfg" of the KGS at this time and maintain it in your deployment code. (b) You point to a particular release's "versions.cfg", for example "versions-3.4.0.cfg". (I will start producing those starting with the next Zope 3.4 release. Maybe I should create a versioned file for "controlled-packages.cfg" as well?!) (c) You use a particular SVN revision, download `zope.release` yourself and generate the "versions.cfg" file, which is trivial. I already create tags for releases there. I probably would prefer option (b). > This breaks a fundamental assumption for releases. When I release > something, I expect it to work tomorrow, next month, and next year. I agree. The KGS should be seen as a branch. Particular versions of "versions.cfg" and maybe "controlled-packages.cfg" should be considered releases. > With code, we know that history, and branches, and so on, are important. > We use Subversion. With KGS we only have an ongoing trunk. No, as I said before, the KGS specification, which is "controlled-packages.cfg", is maintained in SVN as well. > With Grok, we use an external versions list. We can use this to solve > the above problem. We basically take snapshots of what is in KGS. This > allows us to maintain some history, though it isn't ideal either, as > it's quite a bit of overhead. How is this overhead? > If I build an application or framework on top of Grok, I will need to > maintain yet another external list for the extra packages of this > application, fixing those versions. Why? I don't follow that? > We could probably even use the > extends feature of buildout to have this list point at Grok's list so we > have to repeat ourselves less should we want to build something on top > of *that* application or framework again. I don't understand what you are saying. However, I'll note that the KGS is also extendable. For example, Grok can maintain its own "controlled-packages.cfg" that extends a particular Zope 3 "controlled-packages.cfg". Extending also means that you have the choice of overwriting a particular version requirement. (I have implemented this after the discussion yesterday.) Having a "controlled-packages.cfg" does *not* mean you need an index. This file can be used to generate a "versions.cfg" file or just a `[versions]` section for buildout. > So, while annoying, that is somewhat manageable. No
AW: [Zope-dev] Doc strings of IContentProvider
> Betreff: [Zope-dev] Doc strings of IContentProvider Hi Thomas > While trying to implement the outcome of that zope3-dev > discussion on pagelets being content providers, I noticed > that the doc strings for IContentProvider talk about how > content providers are to be looked up: > They specify (informally) that content providers are > discriminated by context, request, and view. Also, the > documentation of the __parent__ attribute states that the > parent is a view. > > To my understanding, the interface should only specify how an > object behaves, not how it is obtained. Moreover, I suspect > that it might be enough to require the presence of a parent > for the sake of the security context (as stated in the doc > string) without specifying that it must be a view. The way it > is now, a view whose parent is something other than a view > can never be its own content provider. As an example, this > includes pagelets. Unless this is a conscious design choice, > IMHO the interface's documentation should be worded more liberally. The IContentProvider interfaces is a marker interface which describes what a component must support that it get collected by the Tales Expression. We didn't define the __init__ signature because we didn't know if there are other usecases which will need different adaption later and it's also not common to restrict the __init__. But we should do that if we change something. This means the IContentProvider interface is not designed for general porpose. It's the provide interface for the TALES expression collection concept! e.g. provider = zope.component.queryMultiAdapter( (context, request, view), interfaces.IContentProvider, name) Every other interpretation of IContentProvider is irrelevant or just something that should be defined with another interface. The IPagelet is not a content provider. A Pagelet is a enhanced BrowserPage pattern which offers support for a layout and content interface by useing the adapter registry instead of the use-macro pattern. And it uses the provider pattern for doing a recursive call for calling the layout template from the renderer. The PageletRenderer provides the IContentProvider interfaces and the IPagelet provides the IBrowserPage interface. I'm not really sure what you are trying to do or improve. I'm fine if you like to improve the documentation, but note, the IContentProvider is there for to describe what a object must provide that the TALES Expression concept works. Of corse the IContentProvider can be used without the TALES expression concept. But the TALES expression does not work with out the IContentProvider interface. This means any change to IContentProvider must still be valid for the TALES exrpression *implementation*. I hope that helps to understand our motivation at the time we implemented this. Thomas, Any new ideas are welcome, the description above doesn't mean we can't improve something. Regards Roger ineichen > -- > Thomas > > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Nov 11, 2007, at 2:06 AM, Martijn Faassen wrote: Hi there, I've been doing some more thinking about external version indexes (like Grok's versions.cfg on a URL, and like KGS) and why they won't solve all our problems. I have a new way to express it, so let me try it out on you all. What KGS solves is that it allows the ongoing development and testing of an integrated Zope 3. I see it addressing a more general problem of having a known good combination of components that work together. There's nothing Zope 3 specific about this. That is, there's a Zope 3 'trunk' of versions that keeps being updated as there are bugfix releases. That's not how I see it. As I've said before, I would model this on linux distributions, where each feature release has a repository of packages for that release, including bug fixes. I'm not sure what happens as soon as someone wants to make a new feature release of any package. They make a new release. At some point, someone will make a new KGS that incorporates this. Presumably they end up in KGS too. After all, we won't have a single Zope 3.4 and then a single Zope 3.5 for which we can create a new KGS. Why not? I would expect that there would be Zope 3.4 and Zope 3.5 KGSs. There might be additional KGSs that include some of the same components. Anyone can assemble a KGS if they think that in doing so, they can add value. We intend to let packages move at different feature-release speeds, and we can't have a KGS for each package. Of course not. Another problem KGS can solve is to add some release hygiene to the cheeseshop: do not remove old releases or overwrite them. I don't really understand this. Maybe you mean that a KGS can be a better alternative to the cheeseshop. I can certainly see that. What KGS doesn't have is history. When I release an application or framework and I used KGS to make sure that all my versions were correct, it will work on the day of release. As soon as enough bugfix (or feature) releases make it to KGS, something will inevitably break. We've seen innocuous changes breaking code a lot of times, so we can't pretend that never happens. It *will* happen. Yup. Which is why you should record versions you use. This breaks a fundamental assumption for releases. When I release something, I expect it to work tomorrow, next month, and next year. If you want this, then you can't rely on the KGS. When releasing our applications, we don't rely on a KGS. We fix all of the versions we're using. IMO, the KGS shouldn't try to solve this problem. A KGS should be helpful for developers and development frameworks. A KGS will be more useful if the quality remains high. A KGS is similar to a traditional monolithic release. After all, bug fix Zope releases have been known to break applications too. With code, we know that history, and branches, and so on, are important. We use Subversion. With KGS we only have an ongoing trunk. I'm not sure why you keep saying "trunk". I'm not sure if you are being imprecise, or if I'm missing something. There's no reason a KGS couldn't be managed with a revision control system. That might be a very good idea. With Grok, we use an external versions list. We can use this to solve the above problem. We basically take snapshots of what is in KGS. This allows us to maintain some history, though it isn't ideal either, as it's quite a bit of overhead. Yup. I think both KGSs and version lists are valid approaches. Each has different strengths and weaknesses. If I build an application or framework on top of Grok, I will need to maintain yet another external list for the extra packages of this application, fixing those versions. We could probably even use the extends feature of buildout to have this list point at Grok's list so we have to repeat ourselves less should we want to build something on top of *that* application or framework again. Yup. So, while annoying, that is somewhat manageable. Now imagine I want to use a completely separate Python library with my Grok application. This python library has dependencies itself again. This means I will need to know about versions of those dependencies as well, and fix them into my application's list. Yes There are some fundamental problems with external lists or indexes: * we need to know about the dependency of dependencies, even if we never use them directly. Information hiding is broken. I'm not sure how this is a problem with version lists (external or otherwise) or indexes. * a single list will never do it. We intend to have many different applications that may depend on different versions of packages. Grok may need a newer zope.publication than your application does. A Grok extension may need an even newer version than Grok does. We'll be baking endless amounts of lists this way. I think each application will need t
[Zope-dev] Re: Hivurt code hosting
Jodok Batlogg wrote: I'm looking for place to host our source code for Hivurt. svn.zope.org + launchpad.net as the rest of the zope world? That is mean that all our developers need signed contribution agreement and writing rights to submit code into zope repository and be members of Zope Foundation? I don't think every ZoFo member agree with this. launchpad.net from other hand is best place, especially if zope3 is hosted here. -- Mikhail Kashkin, skype:mkashkin, jabber:[EMAIL PROTECTED] Key Solutions (http://keysolutions.ru/) Offshore Zope3 development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hivurt code hosting
On 11.11.2007, at 19:41, Mikhail Kashkin wrote: Hello, I'm looking for place to host our source code for Hivurt. We have some choices to use our and switch to free services. As one of the best it Google Code, but it have strict license policy. And there is no ZPL in list. ZPL is GPL compatible, but it is not the same. Second SF.NET, but, AFAIK, it has a lot of problems. What you can recommend? svn.zope.org + launchpad.net as the rest of the zope world? -- Mikhail Kashkin, skype:mkashkin, jabber:[EMAIL PROTECTED] Key Solutions (http://keysolutions.ru/) Offshore Zope3 development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) smime.p7s Description: S/MIME cryptographic signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Doc strings of IContentProvider
On Nov 11, 2007 1:34 PM, Thomas Lotze <[EMAIL PROTECTED]> wrote: > To my understanding, the interface should only specify how an object > behaves, not how it is obtained. That's my understanding as well. The interface should express how a provider of the interface behaves; larger pictures should be documented in README.txt or other documentation files. In some cases, a "this is how it work" might be appropriate, and in others it may be more reasonable to describe "here's how it was designed to work." But both of those go beyond the interfaces themselves. > Moreover, I suspect that it might be > enough to require the presence of a parent for the sake of the security > context (as stated in the doc string) without specifying that it must be a > view. The way it is now, a view whose parent is something other than a > view can never be its own content provider. As an example, this includes > pagelets. Unless this is a conscious design choice, IMHO the interface's > documentation should be worded more liberally. I'm not knowledgeable enough about the pagelet and viewlet models to have a meaningful opinion on this. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Hivurt code hosting
Hello, I'm looking for place to host our source code for Hivurt. We have some choices to use our and switch to free services. As one of the best it Google Code, but it have strict license policy. And there is no ZPL in list. ZPL is GPL compatible, but it is not the same. Second SF.NET, but, AFAIK, it has a lot of problems. What you can recommend? -- Mikhail Kashkin, skype:mkashkin, jabber:[EMAIL PROTECTED] Key Solutions (http://keysolutions.ru/) Offshore Zope3 development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Doc strings of IContentProvider
While trying to implement the outcome of that zope3-dev discussion on pagelets being content providers, I noticed that the doc strings for IContentProvider talk about how content providers are to be looked up: They specify (informally) that content providers are discriminated by context, request, and view. Also, the documentation of the __parent__ attribute states that the parent is a view. To my understanding, the interface should only specify how an object behaves, not how it is obtained. Moreover, I suspect that it might be enough to require the presence of a parent for the sake of the security context (as stated in the doc string) without specifying that it must be a view. The way it is now, a view whose parent is something other than a view can never be its own content provider. As an example, this includes pagelets. Unless this is a conscious design choice, IMHO the interface's documentation should be worded more liberally. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin6
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 zc-bbwin6. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 3425 Blamelist: adamg,ctheune,gregweb,nikhil_n,oestermeier,philikon,srichter,torsti BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] why external version indexes don't fulfill all use casesfor development
Hi Martijn > Betreff: [Zope-dev] why external version indexes don't > fulfill all use casesfor development > > Hi there, > > I've been doing some more thinking about external version > indexes (like Grok's versions.cfg on a URL, and like KGS) and > why they won't solve all our problems. I have a new way to > express it, so let me try it out on you all. > > What KGS solves is that it allows the ongoing development and > testing of an integrated Zope 3. That is, there's a Zope 3 > 'trunk' of versions that keeps being updated as there are > bugfix releases. I'm not sure what happens as soon as someone > wants to make a new feature release of any package. > Presumably they end up in KGS too. After all, we won't have a > single Zope 3.4 and then a single Zope 3.5 for which we can > create a new KGS. We intend to let packages move at different > feature-release speeds, and we can't have a KGS for each package. [...] I hope I can show you another point of view, but I'm not sure if this is understandable what I'll try to explain ;-) Yes, a KGS is a policy which makes sure that we can reproduce the dependency list and build a base for your custom development. Or we can use it as a base for reproducable bugfix. KGS is also comparable with a (daily, monthly or whatever) snapshot. And yes, there will be more then one KGS, there will be a development KGS that allows us to develope in a community. Because probably someone likes to develop 3.6.1 and other still work on 3.5.9. The KGS 3.4 reflects the tags folder compared to subversion and the KGS 3.5 dev will reflect the ongoing development compared with the subversion trunk. Anyway, a KGS is only a definition of what works with what. It doesn't matter if we call it KGS or something else, if you need to build grok or a custom set of eggs for your project you will need to know which version of eggs your project will use. That's the part what KGS can solve. Every egg version which is fixed in a package can break what you are trying to assamble. Because versions in eggs depend on the overall snapshot concept and don't know future versions of other eggs. The KGS can solve the problem because a KGS is a snapshot view on what you are trying to assamble. Eggs can't do that by itself. I'm 100% sure that we are not able to solve the dependencies at the package level. Or at least not without to restrict and lock down packages. Because you will lock down versions in zope package because grok will break but other projects do not. Let's give you a sample: The package zope.subscriber (3.5) defines a new subscriber and zope.catalog (3.5) uses this subscriber. And we have package zope.folder (3.5) which fires a notify for this subscriber. If you will use the new subscriber and it's automaticly handling you will define that all version must be 3.5. But t's also possible to use version (3.5) of zope.subscriber and implement in your custom container implementation the new subscriber pattern from zope.subscriber (3.5). The package zope.catalog and zope.folder can still be at version 3.4. Probably the sample above is not so good. But think about small zope.* package based distributions and the dependency to the ZODB package. I'm sure there it is possible to assamble many different versions of the ZODB egg within different versions within other zope.* packages. If any of them defines a version for ZODB, you will get very quickly into troubles. (You can still apply a patches if you like to use an older ZODB and if something doesn't fit) If we need to define versions, then a KGS is the concept which allows you to define this set. And this means that the versions defined in eggs are obsolate. I guess Stephan implemented this feature yesterday. Fazit, If we like to see different Zope 3 based distributions like Zope 3 itself, Grok or Z3Ext etc, it must be possible to assamble all the package within different versions of zope.* packages. And then it doesn't make sense to fix version in packages, right? Stephan, do you know what I mean, was this understandable or can you give additional hints? Regards Roger Ineichen _ END OF MESSAGE > Regards, > > Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Sat Nov 10 13:00:00 2007 UTC to Sun Nov 11 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Nov 10 20:52:20 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008626.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Nov 10 20:53:50 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008627.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Nov 10 20:55:20 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008628.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Nov 10 20:56:50 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008629.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Nov 10 20:58:22 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008630.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
Previously Martijn Faassen wrote: > People have been saying that since Linux distributions use external > indexes, we should too, as we are dealing with the same problem as Linux > distributions. While the problem is similar, I think the nature of > development makes our problems, and therefore our solutions, quite > different from the way distributions do it. > > How are we different? > > We have many, many different small distributions (package + > dependencies) that can be combined. We have such a small distribution > for each application. We have such a small distribution for each > extension. Not just that. We have such a small distribution for each > *release* of an application. We have such a small distribution for each > *release* of an extension. > > I therefore still believe that version dependency information should > move out of external indexes and into packages. Unless I'm missing something that is exactly what Linux distributions are doing. Each package has its own list of dependencies and conflicts (just as important). When a package is uploaded to a distribution archive that information is copied out of the package and included in the distribution index. That is important since it allows you to grab the index and calculate the whole dependency graph without having to download packages. You can know in advance if something is installable without having to download dozens of pacakges and only then discovering that it will never work. Linux package managers can also handle multiple distributions. If you look at apt for example it can handle as many distributions as you want. You can set priorities for them at distribution-scale (ie always prefer packages from distribution X), at release scale (ie always prefer packages from release Y even if release Z has a newer version) or package scale (package A has to come from distribution X). This is extremely common. If you install a Debian or Ubunutu machine you will always use two distributions: the one for the release, which will never change, and one with security fixes for just that release. Often you will also configure distributions with specific backports (needed because Debian releases are far apart) or for specific products (for your Enlightement 17 snapshot for example which Debian does not have). The terminolpgy is slightly different (archive versus index, package versus egg, depends versus requires, enlightenment versus grok, etc.) but the problem is still the same. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Nov 11, 2007 8:06 AM, Martijn Faassen <[EMAIL PROTECTED]> wrote: > I therefore still believe that version dependency information should > move out of external indexes and into packages. This is at least the intuitive place for this information. My application requires Grok 0.11, which requires zope 3.4.0b2 which then would be a package that doesn't contain any code, just requirements of eggs that in turn has requirements of their own. I'm not even sure this *is* different from how the unices does it, but it just seems the obvious way of doing it. I would be interested in knowing if this has drawbacks. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
