Re: [Zope3-dev] Nine new ZC Zope 3 packages
Gary Poster wrote: [snip a few things that we think would be nice and useful for the packages] Sure. I'd love to. I'm happy if I at least get the stuff open- sourced, though. Life is full of compromises. I understand the spirit in which these were donated to the community, and it's appreciated. Note that I'm in the same state with the 'hurry' package; it's also sitting off in an svn repository somewhere without a release. I just wanted to start talking about the next step to make the status of these packages more clear. Stephan and I have been talking, and he has a lot of ideas about how to start managing this, so I'll wait for his proposal and comment on that. [snip questions on how to install these packages] Sure, if you like. I'm cool with whatever, as long as it doesn't add too much ceremony to actually open-sourcing our code. For those watching at home, one obvious alternative for UNIX-based systems is symlinks; less obvious but cross-platform alternative is using pkgutil.extend_path from the standard library. I'm concerned about those developers, or system administrators later on, who unlike you and me, do not have the patience to figure it out for themselves. I'm not cool with whatever myself, as I will need to explain it to others and I'd prefer a single obvious way to do it in that case. I'm also worried about putting non-core packages into the namespace 'zope'. It's unclear what ZC's policy is in this; some packages are in the 'zope' namespace, other packages are in 'zc'. And not only ZC is adding things to the 'zope' namespace; there's zope.paste, for instance. We don't have a policy, we have intelligence guided by experience, since we've never done anything like this before. Okay, so then we're free to make up a policy for the future. :) Note that Jim wants to make the zope package in the repository smaller, and divide up the zope namespace into separate projects that can be knit together. We don't know how this will work yet, which is what conversations like yours will hopefully suss out. Exactly. FWIW, right now generally the zope namespace for us includes things that we (a) know from the beginning that we want to open-source, and (b) are fundamental, things that in the past we would have just added to the repo because we would have been confident that the world wanted them as part of Zope. Maybe we'll do zc packages exclusively from now on. That'll make it a bit more consistent, which is good. I saw that the new zc packages appear to all have a 'src' directory which contains the code itself - that's a good consistency. We can put README.txt, dependency information and setup.py and the like in the outer package eventually. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Zope Foundation Imminence (was Re: [Zope3-dev] Nine new ZC Zope 3 packages)
On Feb 6, 2006, at 9:52 AM, Chris McDonough wrote: BTW, how impending is impending? Days, weeks, months? Anybody know? The word on the street is a pretty small number of weeks. (I believe the general idea at ZC is to not announce any precise guess as to exactly how impending we think things are, so people don't get mad at us if we miss a timeframe over which we have no control.) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Nine new ZC Zope 3 packages
On Monday 06 February 2006 06:13, Martijn Faassen wrote: Is this stuff intended to end up in the zope core eventually? If so, what steps will need to be taken? I imagine this also ties into the eggs story, but the question on the zope core perhaps still stands - what would be a dependency of the zope core? In light of the recent discussion at the Plone Snowsprint, there is a general desire to have a common repository for Zope 3 addons that are useful, but might not be appropriate for the core. In my opinion we would like to be able to control the license and quality of this repository. Basically, it should be core-quality/ready code in an add-on place. Thus, it would also require those packages to follow the Zope 3 development process. I have had positive feedback about this idea from the Plone developers. In the coming weeks I am going to be involved in this sort of discussion hopefully on this and the plone-dev list. I welcome any initial ideas and comments. (Of course, Martijn and I can/will use the opportunity of being at the physically same location this week to talk about this offline.) 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] Nine new ZC Zope 3 packages
Stephan Richter wrote: On Monday 06 February 2006 06:13, Martijn Faassen wrote: Is this stuff intended to end up in the zope core eventually? If so, what steps will need to be taken? In the coming weeks I am going to be involved in this sort of discussion hopefully on this and the plone-dev list. I welcome any initial ideas and comments. My first thought is to consider how the impending charter of the Zope Foundation influences things. -- 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] Nine new ZC Zope 3 packages
Chris McDonough wrote: BTW, how impending is impending? Days, weeks, months? Anybody know? On Feb 6, 2006, at 8:40 AM, Benji York wrote: My first thought is to consider how the impending charter of the Zope Foundation influences things. Good question. My response to this would be two sided: * Zope Foundation, great! * but we will end up doing the work anyway, so let's talk about what needs to be done? 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] Nine new ZC Zope 3 packages
On Monday 06 February 2006 09:57, Martijn Faassen wrote: Chris McDonough wrote: BTW, how impending is impending? Days, weeks, months? Anybody know? On Feb 6, 2006, at 8:40 AM, Benji York wrote: My first thought is to consider how the impending charter of the Zope Foundation influences things. Good question. My response to this would be two sided: * Zope Foundation, great! * but we will end up doing the work anyway, so let's talk about what needs to be done? I agree, I am more interested in version control layout, license, and quality assurance. I am pretty sure that all of this will be under the Zope Foundation, but I am not going to worry about it till it happens. 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] Nine new ZC Zope 3 packages
(apologies to Martijn and Stephan for repeating this email: zope.org rejected my previous emails) On Feb 6, 2006, at 6:51 AM, Martijn Faassen wrote: Stephan Richter wrote: On Monday 06 February 2006 06:13, Martijn Faassen wrote: Is this stuff intended to end up in the zope core eventually? If so, what steps will need to be taken? I imagine this also ties into the eggs story, but the question on the zope core perhaps still stands - what would be a dependency of the zope core? In light of the recent discussion at the Plone Snowsprint, there is a general desire to have a common repository for Zope 3 addons that are useful, but might not be appropriate for the core. In my opinion we would like to be able to control the license and quality of this repository. Basically, it should be core-quality/ ready code in an add-on place. Thus, it would also require those packages to follow the Zope 3 development process. I have had positive feedback about this idea from the Plone developers. Also important is regular releases for these packages. Sure. I'd love to. I'm happy if I at least get the stuff open- sourced, though. Life is full of compromises. Released versions do: * publicity * make it clear for which zope version my add-on package release is going to work. Right now it's unclear whether the add-ons are for Zope 3.2, or Zope 3 trunk, or what. FWIW, for this particular example, most of the new ZC ones are developed on trunk, and several of them are also tested on 3.2. No way to know that looking at 'em, I know. Additionally, we should make it easy for people to install these packages in a canonical way. Right now, this is confusing... I had some things to say about general package layout here: http://faassen.n--tree.net/blog/view/weblog/2005/10/07/0 With a package in the 'zope' namespace, what am I supposed to do when I install it? Symlink it into lib/python of my Zope 3 software home? When I have two separate packages in the zc namespace, how am I supposed to install that? I can get it all working of course, but it's non-obvious and there are multiple ways to do it. There should a single obvious way to do it. Sure, if you like. I'm cool with whatever, as long as it doesn't add too much ceremony to actually open-sourcing our code. For those watching at home, one obvious alternative for UNIX-based systems is symlinks; less obvious but cross-platform alternative is using pkgutil.extend_path from the standard library. I'm also worried about putting non-core packages into the namespace 'zope'. It's unclear what ZC's policy is in this; some packages are in the 'zope' namespace, other packages are in 'zc'. And not only ZC is adding things to the 'zope' namespace; there's zope.paste, for instance. We don't have a policy, we have intelligence guided by experience, since we've never done anything like this before. Note that Jim wants to make the zope package in the repository smaller, and divide up the zope namespace into separate projects that can be knit together. We don't know how this will work yet, which is what conversations like yours will hopefully suss out. FWIW, right now generally the zope namespace for us includes things that we (a) know from the beginning that we want to open-source, and (b) are fundamental, things that in the past we would have just added to the repo because we would have been confident that the world wanted them as part of Zope. Maybe we'll do zc packages exclusively from now on. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Nine new ZC Zope 3 packages
(Apologies to Martijn for the dupe; again, zope.org rejected my previous mail) On Feb 6, 2006, at 6:13 AM, Martijn Faassen wrote: Gary Poster wrote: [snip lots of cool stuff] Great, more stuff to play with! :) Just saw zope.file; this begs to be combined with hurry.file's smart upload feature, where the server retains the file so that validation feedback forms work with files. ZC has released many other useful standalone projects on zope.org over the past few months, including zope.file, zope.ucol, zope.locking, and zc.catalog. They all are worth a look. What's the thinking about moving some of this into the zope core? Additionally, at Infrae we have the hurry package that contains some stuff that might be useful to fold into the core (in particular hurry.query and hurry.file, combined with zope.file). Proposals for all of this stuff sound *great* to me. We didn't propose it simply because we don't have time. We didn't want open sourcing our code to be contingent on having enough time to make the proposals and do the package rearrangements. Is this stuff intended to end up in the zope core eventually? If desired. Pretty sure that zope.locking, zope.file (once blob support is in), and zope.mimetype ought to go in the core. we have a zope.html that we'll get out soonish too (based in some TIKS integration of FCKeditor--thanks Roger!) that we expect to be in the core. We're not sure if in the core means in the Zope 3 repo: as I said in the other message, check with Jim on that. If so, what steps will need to be taken? Someone will need to propose what they want to merge, and reconcile with Jim what that means in terms of repo and releases. We'll help. I imagine this also ties into the eggs story, but the question on the zope core perhaps still stands - what would be a dependency of the zope core? Did I already answer this? I'd be happy to have most of zc.catalog go in zope, and maybe some other parts of the new packages. It's a combination of what the community thinks ought to be part of a core release; how that will affect our packaging story, as you said; and who is going to do the necessary proposing and knitting. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Nine new ZC Zope 3 packages
Hi Gary [...] If desired. Pretty sure that zope.locking, zope.file (once blob support is in), and zope.mimetype ought to go in the core. we have a zope.html that we'll get out soonish too (based in some TIKS integration of FCKeditor--thanks Roger!) that we expect to be in the core. Yeah, cool btw, thanks for the nine great packages. I'm looking forward to use them. Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
