Re: [Zope3-dev] Release schedule and deprecation decisions
Jim Fulton wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) +1 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 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] zope.schema: defaults for non-immutables... questions
I'll keep getting Jim's agreement or putting up a proposal in mind. As I start to think of how to extend it, I have some general question about zope.schema. I should note that I am not currently a zope user proper (though I will be soon), but was referred to the zope.interface package via twisted. When I looked at it, and the zope3 book, I immediately thought that type checking of attributes could be useful, and so started using zope.schema. I've thought of several things I'd like to see in it The biggest would obviously be (optional) type checking of method calls, together with a more robust Method definition. Also it would be nice to have something like delegateImplementation( iface, cvar ) and delegateProvision( iface, ivar) to delegate the fulfillment of an interface to a class variable or an instance variable. But my overall question is: since zope.schema is generally useful for components, why is it separate from zope.interface? I can think of two answers: one, pragmatically, zope3 wants a stable zope.interface so the rest of the system can come up to speed. Thus we can think of schema as sort of like the __future__ version of zope.interface. Second, as schema came from abstracting away zope-like features from gui support, it is meant as proto-gui-support. I would argue that, though it does support some features that would be useful for a gui, it is more generally applicable to component-based programming. (I have been using it for-- among other things-- some souped-up database Rows, which support transparently some postgress-specific features. The extra introspection capabilities in zope.schema have been useful.) But maybe Jim resists changes because he has a more specific role in mind for zope.schema, and the development of zope.interface? - Shaun -Original Message- From: Stephan Richter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 05, 2006 4:40 PM To: zope3-dev@zope.org Cc: Gary Poster; Shaun Cutts Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions On Sunday 05 February 2006 14:42, Gary Poster wrote: ...as I said, Jim disagreed with this sort of change the last time it was brought up. Okay, I did not know that. This needs to have a proposal, or at least needs to have Jim weigh in on it, IMO. Yeah, I forgot about a proposal. 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] Selecting a code name
Stephan Richter wrote: On Friday 03 February 2006 12:14, Shane Hathaway wrote: Andreas Zeidler wrote: On Fri, Feb 03 17:24, Encolpe Degoute [EMAIL PROTECTED] wrote: Zope 3 / Revolution ? well, how about Zope3, Reloaded for all the matrix fans out there? :) The idea of release code names adds a little spice. Most people like spices on their food, so why not on their software too? But the naming scheme really has to be based on the Tarzan series. Jim's a Tarzan fan. Okay, I am giving in on this. There is a three step process that will have to be fullfilled to assign a codename to the Zope 3.3 release. I'd say assigning a name is a responsibility of the release manager. It's not something to spend time debating. Are you the release manager for 3.3? If so, and you don't want to assign a name, then by all means forget the idea. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Selecting a code name
On Feb 6, 2006, at 2:31 PM, Paul Winkler wrote: On Mon, Feb 06, 2006 at 01:53:29PM -0500, Benji York wrote: Shane Hathaway wrote: Stephan Richter wrote: Okay, I am giving in on this. There is a three step process that will have to be fullfilled to assign a codename to the Zope 3.3 release. I'd say assigning a name is a responsibility of the release manager. As I understand it the codename idea wasn't to have a codename per release (like Ubuntu), but a name in addition to Zope 3 to help differentiate it from Zope 2. I'm +0 on the latter and -1 on the former. Me too. Me too. Maybe even a +(0x1). Zope 3: Revolution, Zope 3: Renaissance, and Zope 3: Rebirth were my favorites of the bunch. :-) 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 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
[Zope3-dev] Re: [Zope3-Users] Re: Re: Please Guido, pick me, pick me!
(...sigh...apologies to Stephan...) On Feb 6, 2006, at 6:35 AM, Stephan Richter wrote: On Monday 06 February 2006 01:15, Brad Allen wrote: By new website, do you mean a Zope 3 advocacy site, or a general documentation site? Making a separate site for advocacy seems like a no-brainer (ala Pythonology.org), but the documentation site is another matter. Have the Zope 3 core developers decided to split Zope 3 documentation onto a completely separate site? Maybe this has already been discussed on the Zope3-dev list, which I haven't yet looked at. Any site, any focus would be good. Anything at all is an improvement! :-) +1. Do what you think ought to be done, and we'll all simultaneously kibbitz wildly and be *very* appreciative. :-) 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] Selecting a code name
Gary Poster wrote: Me too. Maybe even a +(0x1). Zope 3: Revolution, Zope 3: Renaissance, and Zope 3: Rebirth were my favorites of the bunch. :-) Well, a new name for Zope 3 sounded like such a bad idea that it didn't even occur to me that someone would suggest it. We'd have to live with whatever name we choose. Arghhh! I'm not sure I could handle the pain. ;-) Release names would be OK because they change often. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Selecting a code name
On Feb 6, 2006, at 3:26 PM, Shane Hathaway wrote: Gary Poster wrote: Me too. Maybe even a +(0x1). Zope 3: Revolution, Zope 3: Renaissance, and Zope 3: Rebirth were my favorites of the bunch. :-) Well, a new name for Zope 3 sounded like such a bad idea that it didn't even occur to me that someone would suggest it. We'd have to live with whatever name we choose. Arghhh! I'm not sure I could handle the pain. ;-) Release names would be OK because they change often. LOL. :-) I don't feel strongly about it...unless someone who actually makes a marketing effort feels strongly about it, in which case I'm 100% behind whichever way they feel. ;-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Selecting a code name
On Mon, 06 Feb 2006 17:27:43 -, Shane Hathaway [EMAIL PROTECTED] wrote: Stephan Richter wrote: On Friday 03 February 2006 12:14, Shane Hathaway wrote: Andreas Zeidler wrote: On Fri, Feb 03 17:24, Encolpe Degoute [EMAIL PROTECTED] wrote: Zope 3 / Revolution ? well, how about Zope3, Reloaded for all the matrix fans out there? :) The idea of release code names adds a little spice. Most people like spices on their food, so why not on their software too? But the naming scheme really has to be based on the Tarzan series. Jim's a Tarzan fan. Okay, I am giving in on this. There is a three step process that will have to be fullfilled to assign a codename to the Zope 3.3 release. I'd say assigning a name is a responsibility of the release manager. It's not something to spend time debating. Are you the release manager for 3.3? If so, and you don't want to assign a name, then by all means forget the idea. Guys ... from my reading of the z3-user discussion, there were two subtly different things that came out: - Have funky release codenames. Okay, good - makes it easier to talk about Zope 3.2 vs. 3.3. However, I think this is secondary (by far) to ... - Have a *brand*. That means one name, a name that doesn't change. It could just be Zope 3 with a capital 3, or it could be a more distinctive name, e.g. Zope 3 Zomething (where Zomething is something to be decided) to have an even more distinctive brand; a logo that has some punch, a colour scheme, a web site with proper advocacy and some start-here documentation and some quick tutorials. The secondary brand name (the Zomething in my example above) was the original example - and I personally think this is a good idea, just to give the clear message that this is distinct but building on Zope 2. Seriously, look at http://www.djangoproject.com or http://rubyonrails.com. This is about getting people to *understand* what Zope is about, to understand that we *care* that they understand and that we made an *effort* to make it easy for them to get into it. It's about lowering the barrier to entry and the risk that they'll spend time learning something that'll turn out to be a dead end. It's about showing off that Zope can be sexy and knock the socks off the competition. It's about generating some excitement, not just a dreary list of technical blather. This is the proposal that considers the most serious consideration in my opinion. The original discussion showed that a lot of people found Zope's lack of branding a problem. Now it's time to find a solution to that problem. (or so I hope) :-) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Broken homefolder tests
Hi Florian, and other unittest gurus? The README.txt test in zope.app.homefolder is failing (trunk). This happens because the zope.app.file.file.File doesn't implement IAttributeAnnotatable in the test setup. The bad thing about this is, that the tests are running if you run all tests at once. This smells like a missing teardown in another test. Does somebody know if there is a method for check if a teardown get called after a test? Some hints? Regards Roger Ineichen ___ 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
[Zope3-dev] Re: Nine new ZC Zope 3 packages
IMHO, Zope 3 repository can be much smarter than Plone or other. I think it is possible to generate some interactive documentation based on ++apidoc++ mechanics and publish it in Product area on future zope3.org. Stephan Richter wrote: On Monday 06 February 2006 06:13, Martijn Faassen wrote: 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 -- Mikhail Kashkin, Key Solutions (http://keysolutions.ru/) Zope/Plone Consulting/Hosting/WebDev Plone на русском http://plone.org.ru/ Plone Foundation Member (http://plone.org/foundation/members/) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML bad ;-)
Shane Hathaway wrote: Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. +1 Shane +1 from me and +5 people around who completely stuck in ZCML -- Mikhail Kashkin, Key Solutions (http://keysolutions.ru/) Zope/Plone Consulting/Hosting/WebDev Plone на русском http://plone.org.ru/ Plone Foundation Member (http://plone.org/foundation/members/) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Zope 3 Marketing Competition? (was Re: [Zope3-dev] Re: Selecting a code name)
On Feb 6, 2006, at 5:37 PM, Martin Aspeli wrote: [...] This is about getting people to *understand* what Zope is about, to understand that we *care* that they understand and that we made an *effort* to make it easy for them to get into it. It's about lowering the barrier to entry and the risk that they'll spend time learning something that'll turn out to be a dead end. It's about showing off that Zope can be sexy and knock the socks off the competition. It's about generating some excitement, not just a dreary list of technical blather. [...] How about we have a marketing competition? :-) The goal would be to set a date, like end of February or end of March, at which point everyone would submit their entries. Entries would be something like a one-to-three page brochure website. We'd vote...maybe within categories like 'marketing copy', 'layout', 'logo', and 'overall concept'. Winners would have net fame, and we'd put top contenders up on a zope*.org site. Maybe we could do something else small for the winners too? Any ideas? Minimal requirements to get this to happen: - final submission date - enough people committing to have an entry (maybe 10? 15? I think *everyone* potentially has something to offer here, so the numbers would ideally be even bigger...but I won't hold my breath :-) - someone willing to organize - a web site to post the results to. ;-) If the due date is in March or later, I'll volunteer to organize, if there's enough interest and then enough commitments to enter. That said, if someone else wanted to volunteer to organize, I'd gladly hand the reins over. ;-) Is this crazy? Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release schedule and deprecation decisions
Jim Fulton wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) Jim + 1 (Hope this mean that Philip's Book be useful for 1 year) -- Mikhail Kashkin, Key Solutions (http://keysolutions.ru/) Zope/Plone Consulting/Hosting/WebDev Plone на русском http://plone.org.ru/ Plone Foundation Member (http://plone.org/foundation/members/) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Local Component Management Simplification
Stephan Richter wrote: On Friday 03 February 2006 17:23, Dieter Maurer wrote: Stephan Richter wrote at 2006-2-3 12:45 -0500: ... declareSite name=mysite / site name=mysite / !-- normal directives here. -- /site The declareSite looks redundant. I see at the site name='mysite' element that a site with name mysite is declared... No it is not. Explicit is better then implicit. declareSite creates a new site in the sites mapping. We use this pattern for layers and skins already. Can you have site... directives without a corresponding declareSite...? What would that achieve? Suresh ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
