[Zope3-dev] Re: tracking satellite project's trunks
Jim Fulton wrote: On May 4, 2007, at 6:25 AM, Baiju M wrote: ... We will be using same Zope 3 resources for bug tracking, mailing list and wiki for these satellite project's, is it ? Thanks a very good question. I don't think we need more mailing lists. In fact, I think zope3-dev and zope-dev should be merged. I suspect that these projects will eventually get their own projects in launchpad, but I'm not sure. I'm also not sure about wikis. I don't think we need to do anything about this any time soon. It sounds like we're in the distribution business, and have problems similar to a Linux distribution. Since Ubuntu's requirements are in a large part driving Launchpad development, we should examine what Ubuntu is doing. I got the impression one of Launchpad's underlying goals it to make it easier for upstream (the package developers) and downstream (the distribution developers) to collaborate on critical information such as bugs. I don't know what the concrete status of this is for Launchpad however. I think we should be asking Steve. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
Benji York wrote: Christian Theune wrote: Same here. I'm feeling like I'm not yet understanding what the trunk will be used like. I'm wondering if we need to maintain a Zope 3 project with any code in it at all (or nearly so). Could Zope 3 just be a buildout with a configuration that creates a Zope 3 application with a bunch of stock components. Christian said we should wax philosophical and since this one of my favorite activities I will belatedly do this. :) It is instructive to look at TurboGears. They were the pioneers of egg-based distribution and used cool words like 'megaframework' to market the concept of various libraries being integrated into one framework. Django in contrast spreads memes like yeah, megaframeworks are nice, but we're INTEGRATED. So we could market Zope 3 as the integrated mega-framework. :) TurboGears is different from Zope 3 in that most of its component parts are libraries developed by independent communities. This is less the case for Zope 3, though some of its constituent parts are similar (ZODB for instance). As time progresses we might eventually see more smaller communities form around smaller parts, but we'll see. If I read Jim right, we should be careful about splitting up the community prematurely, so let's all keep it on this list for the time being. :) TurboGears is also different from Zope 3 in that there is an actual turbogears package out there. This contains the code that glues the libraries together into a more coherent experience. With Zope 3 the responsibility for a coherent experience is diffused over numerous packages, though one can argue that zope.component and zope.interface play the most important roles here. It's interesting to consider Grok in this light too. Grok tries to encapsulate various patterns of Zope 3 and offer them in a more convenient to use form. In this, it might be somewhat similar to the role the turbogears core package plays, but of course only to people who actually use Grok. :) Regards, Martijn ___ 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: tracking satellite project's trunks
Christian Theune wrote: Same here. I'm feeling like I'm not yet understanding what the trunk will be used like. I'm wondering if we need to maintain a Zope 3 project with any code in it at all (or nearly so). Could Zope 3 just be a buildout with a configuration that creates a Zope 3 application with a bunch of stock components. -- Benji York Senior Software Engineer Zope Corporation ___ 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: tracking satellite project's trunks
Am Freitag, den 04.05.2007, 12:16 -0400 schrieb Benji York: Christian Theune wrote: Same here. I'm feeling like I'm not yet understanding what the trunk will be used like. I'm wondering if we need to maintain a Zope 3 project with any code in it at all (or nearly so). Could Zope 3 just be a buildout with a configuration that creates a Zope 3 application with a bunch of stock components. Yes it could. However, we don't have enough time to create this kind of buildout. I tried doing that at PyCon and we aren't there yet. It also requires us to deal with upgrading existing instances that are 'old style'. In the future this is likely to happen. Just not for Zope 3.4 Christian -- 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: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Hi, Am Donnerstag, den 03.05.2007, 13:18 -0400 schrieb Tres Seaver: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: On 5/3/07, Christian Theune [EMAIL PROTECTED] wrote: I started moving packages to their own projects (manually right now, preparing for doing this scripted) and noticed that zope.index is tracked with a specific revision number. My understanding is that the trunk of the Zope 3 tree should be tracking the trunk of the satellite project's tree without pinning it to a revision. Probably my fault; I've become really wary of externals that aren't specific. Frankly, I don't *really* care how the Zope 3 tree refers to satellite projects. My hope is that I can very quickly get away from ever looking at the Zope 3 conglomeration (checkout or release), and only use the satellite projects. Conversely, I care very much about the satellite projects not referring to the Zope 3 tree, and look forward to what you're working on today. When a truly egg-based Zope3 ships, it should be a meta-egg with explicitly-versioned dependencies. Approximating that in tree would be to have the Zope3 tree point at *tagged releases* of the satellite projects; revision-stamped versions are a poor (but acceptable in the near-term) substitute. Same here. I'm feeling like I'm not yet understanding what the trunk will be used like. Tracking the trunk of any dependency is not acceptable: it undoes the reason for moving the projects out-of-tree in the first place. If we aren't going to do release management on the pieces, then for sanity's sake keep them in-tree. Plone's own trunk-based bundles are living proof of the hell that is caused by having svn:externals point at non-frozen dependencies. Ah. I don't have any experience with those. What would the trunk of the Zope 3 tree look like then during development cycles? When do updates on the externals in the Zope 3 trunk happen? Typically whenever somebody who knows both decides that the satellite has changes which need pulling into Z3; at the latest, they get updated when doing a Z3 release, I would guess. This is like what happens now with ZODB, etc., or with Zope3 as an external in Zope2. I think we are headed to a place where much less trunk-like development, except for things which have not yet (or maybe ever) been spun off into satellite projects. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOmDp+gerLs4ltQ4RAtYzAJ9E7W9Ate0Ntr1rSxP28wcuk+gROACgrR+g 2HDuD9SkZkEWYpPvU5sRqmI= =UCYx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
Hi, Am Donnerstag, den 03.05.2007, 18:23 -0400 schrieb Tres Seaver: Typically whenever somebody who knows both decides that the satellite has changes which need pulling into Z3; at the latest, they get updated when doing a Z3 release, I would guess. This is like what happens now with ZODB, etc., or with Zope3 as an external in Zope2. Hmm. Right. So those would be less often updated. Typically only after waiting for (a number of) the external packages to have stabilized after new features were added and are gathered together as the classical release. I think we are headed to a place where much less trunk-like development, except for things which have not yet (or maybe ever) been spun off into satellite projects. I'm currently working on getting the whole zope.* and zope.app.* namespace turned into satellite projects. A script is helping me so that should be done pretty soon. Christian -- 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: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
