Re: [Zope-dev] Re: Future of ZClasses
Patrick Gerken wrote: On 10/2/06, Olavo Santos [EMAIL PROTECTED] wrote: Just a quick side note. Many deprecation sign for any user are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a no sir, next app! for guys like us who have to choose opensource development platforms for the long run ( again: think years ). Well, though nothing is perfect in Zope world, I think we are quite good in having a policy about deprecation which already gives a guaranteed timelime for deprecation. I wanted to find a deprecation policy for eclipse and JBoss to compare. For JBoss i did not find such a thing, for eclipse I did not find a eclipse framework one, but one for some sub projects: http://www.eclipse.org/webtools/adopters/#non-api-code-deprecation-policy and somehow this popped up in the eclipse search result: http://maven.apache.org/development/deprecation.html Notice especially how they mention that a deprecation phase can be days. So for me it looks we are actually a bit ahead of the competition, but maybe somebody can correct me. Accidently I lately tripped over an article from Martin Fowler about this topic: http://www.martinfowler.com/ieeeSoftware/published.pdf I think we use Interfaces in Z3 to publish Methods. So maybe it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already. I guess the motivation of this API stability discussion is also motivated by JMOs comment about how much more stable is the Java API, in Point 2 and 3 of this entry: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_09_23_times-they-changin But it is not fair to compare the stability of a programming language standard modules API with a application framework api. But maybe I am not good in searching and somebody points me to the well thought out JBoss or Websphere deprecation policy best regards, Patrick Everyone deprecates stuff, this is not the question. But what is marked as 'stable', 'official' or 'standard' may not be deprecated in the same way as something that is still under development or private. It is more a question of defining and maintaining a contract with API users than a question of technicalities (how often to deprecate, what version numbers to use, how to inform...) This is all about defining and maintaining a social contract with the user. No one prevents you from deprecating parts of an API that is marked as being under development or private -- as long as you say it from the start. Check out for instance: http://openide.netbeans.org/tutorial/api-design.html especially the chapter Life-cycle of an API What is unclear in zope is what is official, what is stable, what is still under development, etc. It seems that all the different packages have the same status, or rather that they have no status. Apart from the packages that were added recently (zc. ...) there is no information in the repository about the quality of the different APIs. There are no version numbers on the packages either so I don't know what is alpha, beta, or final. It gives the impression that the framework is stable, but not mature. I'd expect that the API defined in the 'interfaces.py' files for instance are 'official' in the sense that there is a commitment that the API is ready and that it won't change until the next major version, but I doubt that this is understood by everyone putting stuff into these files. in Java, you can mark a class as 'final', meaning that no one will be able to subclass it, or methods can be marked as 'private'. Abstract classes can specify the methods that must be implemented. Also if a class says that it implements an interface it has to implement it otherwise the code won't compile. Again this is all about defining contracts. Considering the standard JBoss modules, there is no way to compare with zope really since they strive to implement the specifications thoroughly (EJB3, JSR-168, ...) and the APIs are final already, so they don't change. For other modules (e.g. Seam) users are fully aware that parts of the specs may change. For more mature modules such as Hibernate, I am not aware that the API changes between minor versions. best regards /JM ___ 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: [Zope3-dev] Re: [Zope-dev] Two visions
Jim Fulton wrote: Martijn Faassen wrote: Jim Fulton wrote: [snip] I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about: 1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc. I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean? I wasn't trying to define app server. I was describing the Zope app server. Jim why not say that the Zope application server is based on the Z Foundation Libraries (ZFL) ? Z can be interpreted as being short name for Zope without creating a new name for it. which can also be interpreted as the libraries used by the zope foundation software (ZF)? /JM ___ 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: [Zope3-dev] Re: [Zope-dev] Re: Two visions
Martijn Faassen wrote: Philipp von Weitershausen wrote: [snip] I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'. Then again, I really should take Jim's side and stay out of naming decisions. Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time... Regards, Martijn please, not Z, it is an oscar-winning film from the 70's about political corruption, military coup d'état, .. http://www.bbc.co.uk/bbcfour/cinema/features/z.shtml /JM ___ 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] traversable methods / docstrings.
Hi! I didn't know that methods needed to have docstrings to be traversable (it took me some time to find out why I was getting Not found errors on some of a tool's methods). Is there any reason to still have such a feature in Zope2.9? or at least maybe there could be a hint in the trace log. regards /JM ___ 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] traversable methods / docstrings.
Paul Winkler wrote: On Mon, Jan 30, 2006 at 11:34:17AM +0100, Jean-Marc Orliaguet wrote: Hi! I didn't know that methods needed to have docstrings to be traversable (it took me some time to find out why I was getting Not found errors on some of a tool's methods). Is there any reason to still have such a feature in Zope2.9? or at least maybe there could be a hint in the trace log. I thought the docstring requirement only applied to publishing, not traversal per se? Do you get Not found when doing e.g. restrictedTraverse(some_path)? no then it works, and also when methods are called from inside page templates. That's the publisher that doesn't find it. /JM ___ 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: traversable methods / docstrings.
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Marc Orliaguet wrote: I didn't know that methods needed to have docstrings to be traversable (it took me some time to find out why I was getting Not found errors on some of a tool's methods). Is there any reason to still have such a feature in Zope2.9? Publishable methods have docstrings is the oldest security model in Zope / Bobo. It would open unknown security holes in 3rd party applications if we removed that restriction. Even setting the default value of '__allow_access_to_unprotected_subobjects__' to False wouldn't help, because there are many products which set that to True for their objects, relying on the lack of docstring to make their methods safe from direct URL access. In fact, this restriction is *different* than the permission-role one: even methods whose roles are None (i.e. public), and therefore can be called by scripts run by anonymous users, are prevented from being published if they have no docstrings. or at least maybe there could be a hint in the trace log. I *thinK* if you run in debug mode with verbose security turned on, it suggests that as one possible reason. Tres. One extra difficulty when debugging with that model is that .pyc files must be deleted if the .py is modified. since apparently docstrings are ignored during the compilation. But now I know :-) /JM ___ 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] Re: ConflictError's worthwhile to note?
Dieter Maurer wrote: Jean-Marc Orliaguet wrote at 2005-12-4 22:28 +0100: ... In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur by design. This argument is not convincing: In a similar way, I could argue that MemoryErrors are there by design. While it is true that *occational* ConflictErrors are nothing to worry about, a higher rate indicates that you soon may come into trouble -- because the risk increases that the automatic retries will not be able to recover and your users will see errors. Obviously, a ConflictError is far less important than a MemoryError, but a higher rate of conflicts should be analysed and if possible avoided. The conflict rate is related to the quality of your application design. I like quality related information in my logfiles -- to be able to take action before it is too late. But aren't you looking for some sort of application profiler? or some sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, still you wouldn't want to see in the log file: INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already) Similarly if the number of cache objects is too low, the application will run slowly, do you want to see: INFO: 1000 objects loaded into the cache in the last 5 minutes So why not instead create a product that logs occasional conflict errors? there is already in the ZMI in the database management screen some information about cached objects- Why not add the information that you are looking for there instead? /JM ___ 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] Please vote about conflict errors logging
Dieter Maurer wrote: Jean-Marc Orliaguet wrote at 2005-12-2 23:57 +0100: ... on what level to report retried ConflictError ... BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times) That's because the generated messages *were* uninformative. You can see the critical spots (the objects causing lots of conflicts) easily with sane log messages. In my case it's mostly filesystem-based resources (css files, or images) accessed in read mode (zope-2.8.4). But the information no matter where it comes from has very little value compared to other messages in the log file, because these are completely predictable. In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur by design. regards /JM ___ 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] Please vote about conflict errors logging
Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times) 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback Full traceback, since we're in BLATHER mode 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other ERROR /JM (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent ___ 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] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Martijn Faassen wrote: ... Outside the Zope community Zope 3 doesn't have such a great image indeed. It's either ignored, or it's actively rejected. There is a lot of competition with other frameworks. Zope 3 is currently not doing particularly well in this competition, something we need to fix, but that's another topic for another thread. It doesn't change that inviting in the Zope 2 developers is most effective thing we can do at present to grow the Zope 3 community. Regards, Martijn Hi, It is a bit like this: the zope2 community wants the zope3 technology and zope3 wants the zope2 community. I think the question about the technology should be treated as such on a technical level, by bridging the technical gap (Five, common repositories, writing tutorials for zope2 developers, collaborating on common modules, adapting zope2 concepts like TTW editing to Zope3 but without reproducing the zope2 skin and templates mess, etc). But the question about the communities involves more complicated aspects, i.e. marketing issues, licenses, competition, strategies, etc. The repository is not the answer. This has to be solved on a higher level, Zope Foundation, updated ZPL license, ... where a social contract is agreed on. So let's not pretend that everything can be solved on a technological level even though lots of it can .. Regards /JM ___ 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] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Martijn Faassen wrote: Jean-Marc Orliaguet wrote: [snip] It is a bit like this: the zope2 community wants the zope3 technology and zope3 wants the zope2 community. I like this analysis. :) I think the question about the technology should be treated as such on a technical level, by bridging the technical gap (Five, common repositories, writing tutorials for zope2 developers, collaborating on common modules, adapting zope2 concepts like TTW editing to Zope3 but without reproducing the zope2 skin and templates mess, etc). But the question about the communities involves more complicated aspects, i.e. marketing issues, licenses, competition, strategies, etc. The repository is not the answer. This has to be solved on a higher level, Zope Foundation, updated ZPL license, ... where a social contract is agreed on. Be careful with what you're implying with words: marketing aspects more complicated than code, higher level, etc. I don't necessarily agree with the underlying assumptions. While I fully support efforts surrounding the Zope Foundation, I really think that this is not the right level to solve community issues. A Foundation can make social contracts all they like, for instance, but if people in the community don't follow them, nothing will happen. Marketing issues and strategies are frequently happening a bit more subtly than you seem to say here. The difference between the technical and the community level is far less clear than you make it seem. Five, for instance, is *not* just a technical project. It never has been. Five is a community project at least as much, to change people's *minds*, to merge communities, to change the shape of the Zope business, as much as it's to make technical changes. That's why there's talks given about conferences, for instance. These things go hand in hand. Merging the repositories is also not just technical. It's clear enough that it's not -- the discussion in this thread is not about technical issues *at all*. They're about impact on the people involved in Zope 2 and Zope 3 development. So let's not pretend that everything can be solved on a technological level even though lots of it can .. We're in open source. Our solutions are frequently technological *and* community-based. That's the point of open source. Let's not artificially separate the two issues. Regards, Martijn Hi Martijn, I think you're mixing the notions of community and of community of interests. I don't think that the goal is to merge communities, the goal is to make good software and not have different entities fight on framework technologies. It is to stir common *interests* in the technology. On the technical level CMF is used by many, but still different communities. Five is a community project used by different communities. This also shows that technology merge does not entail community merge, because everyone comes with different goals, backgrounds, and this is sound. Python is a community project, not everyone who uses python is in the same community (reads the same mailing-lists, go to the same conferences, develop with zope or twisted, ) even though there is a strong community of interests. I think that you want technology merge in the first place, and not force people into communities through technology. Regards, /JM ___ 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: [Z3lab] Nuxeo supports Zope Corp announces
Philipp von Weitershausen wrote: kit blake wrote: Wow, what a difference two days makes. I heard about the ZF announcement by telephone two mornings ago, and I breathed a huge sigh of relief. It solves a problem we've been worrying about for years. It means we can sit across from a nervous IT director, and when he asks dubious questions about the steering and future of the Zope platform, we can say with certainty, It's in good hands. Reviewing the thread, I'm astonished at the negativity. C'mon, this is a *breakthrough*. It's a move that can ensure the future of Zope. Granted, it's prudent to be cautious, and there's a lot of work to be done, but it's a major step. Shouldn't we be using an Agile approach? As for structure and neutrality, I think decisions should be left up to the developers. If they're not on board, there won't be anything. I'm not much of a developer, I'm a manager, and I know that attempting to pull developers 'over a bridge' is a bad idea. Actually, I'm a vendor too. So wearing all these different stakeholder hats, I'm looking forward to the process. To be explicit: I'm prepared to invest in the future of Zope. I'm sorry if I led anyone believe that I view this process negatively. That is absolutely not the case. I'm as excited and relieved as you, Kit. I personally have been publicly supporting the idea of self-governance of the Zope community for some time now and all of this brings us a huge step closer to it. My concerns regarding the process (which might have interpreted as negativity towards the whole idea) were mainly oriented towards the way the initiation of the process is perceived. All of the self-governance we already have (e.g. zope.org collaboration and maintainance, Zope 3 development process, etc.) has been built up bottom-to-top, just like in any other open source community. Even the wish for self-governance of Zope itself came from the basis and has been expressed publicly since the Castle sprint or even longer. So, my remarks were purely there to state that the perception of this process being nothing but top-to-bottom (IOW, vendor-driven) were a limited view on things. As anything else is mere speculation, I'm looking forward to hearing more details from those who initiated the process. I am confident that everyone in the community will be invited to participate, so that in the end we can all say that we as a community made this happen. Best regards, see you on tuesday in IRC, Philipp Hi! I believe that what is important at this stage is to avoid what we call in French a procs d'intention (I couldn't find the English equivalent) which is a rhetorical figure used to promote a conviction based on speculation about supposed motives rather than facts. The more you address such accusations the more you make them appear as real. regards /JM ___ 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] Re: [Z3lab] Nuxeo supports Zope Corp announces
Philipp von Weitershausen wrote: Jean-Marc Orliaguet wrote: This is really great news! I am going to start working at getting Chalmers to be one of the key players in the foundation which would make the foundation even more vendor-neutral. I am confident that this will go through. This almost sounds as if the Foundation isn't to be vendor-neutral from the start which is certainly not the intention of a foundation. What I like about other open source foundations (take the Plone Foundation from our community, for example) is that the members are developers, not companies. The developers govern themselves, every developer gets a vote. Philipp Hi! I'm a bit confused, first of all Chalmers is a university, it is not a software vendor. Then when I look at the members of the Plone foundation ( http://plone.org/foundation/about/board/list ) I only see companies, except that ZC is not represented. So even if every member gets a vote, how much does that vote count in the development process of Zope2, CMF and Zope3 ? regards /JM ___ 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] Re: [Z3lab] Nuxeo supports Zope Corp announces
Philipp von Weitershausen wrote: Jean-Marc Orliaguet wrote: Philipp von Weitershausen wrote: Jean-Marc Orliaguet wrote: This is really great news! I am going to start working at getting Chalmers to be one of the key players in the foundation which would make the foundation even more vendor-neutral. I am confident that this will go through. This almost sounds as if the Foundation isn't to be vendor-neutral from the start which is certainly not the intention of a foundation. What I like about other open source foundations (take the Plone Foundation from our community, for example) is that the members are developers, not companies. The developers govern themselves, every developer gets a vote. Philipp Hi! I'm a bit confused, first of all Chalmers is a university, it is not a software vendor. Hi! I guess you're right. But then I don't understand how Chalmers as a key player would make the Foundation more neural with respect to software vendors, as you say above. I don't know but how do you make something less vendor oriented? That would require a definition, but essentially you'd bring in non-vendors (such as academic or non-profit organisations) to provide with some sort of balance, instead of hiding companies between individuals' names. How could it be done otherwise? The code that I'm writing during working hours is (c) Copyright Chalmers - it can't be otherwise, but it does not mean that I as a developer have less decision power than the company that I'm working for. Then when I look at the members of the Plone foundation ( http://plone.org/foundation/about/board/list ) I only see companies, I see *people*. If I remember correctly, the Plone Foundation even specifically says no to companies, just like the ASF. Of course, that doesn't mean that officers of the board in the foundation can't be employed somewhere... Btw, you're looking at the board. But still, they're just people, not companies. http://plone.org/foundation/members has the actual members list. These are the people that get to vote. As you can see, I'm in this list and I don't belong to any company. If this was company driven, I wouldn't have a vote. ah OK. I didn't see that list. However, most members do not write code during their free time, do they? What happens when the members write code under working hours, their respective employers must well have something to say about it? except that ZC is not represented. So even if every member gets a vote, how much does that vote count in the development process of Zope2, CMF and Zope3 ? Well, it counts. How much does a vote count when you vote for your parliament? Little. But it counts. Philipp I meant to say that the framework underneath (Zope, CMF) is such an essential component that the development of Plone cannot be dissociated from the development of CMF or Zope, which today happens to be managed outside the Plone foundation. But in the situation where ZC is involved in the foundation as one of the player, obviously the development of the framework and of core components managed by the members of the foundation is less concentrated on one single vendor since others partners have their word to say. This is a give-and-take situation. regards /JM ___ 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: [Z3lab] Nuxeo supports Zope Corp announces
Chris McDonough wrote: On Fri, 2005-06-17 at 07:52 -0400, Stephan Richter wrote: Also, I agree with Andreas and Philipp that developers should be members, not companies. Otherwise, how could I, as an independent developer, have a say? BTW, this is also positive for companies, since they can have several developers being members. In the proposed scenario, my one-man shop would have a lot of power compared to larger companies, such as ZC, Nuxeo, etc. +1 if only because... From what I read from Rob in an interview in LWN, membership to the foundation will be funded by membership dues. I think the dues structure is what will eventually determine who can afford to become a member. I'd definitely pay for membership if I could credibly afford it. It seems like the easiest way to make sure this could happen is to charge on a per-person basis rather than on a per-company basis, with larger companies signing up more individuals as necessary/desired. - C There are different aspects: there is the involvement of individual developers and there is the involvement of the company / university / organisation without which the developers would not be able to sustain development outside their spare time. So reducing involvement to a collection of individual members is not very representative of reality. If a company has put a lot a stake in a given technology (meaning not only financing a handful of developers) but taking a technological risk at supporting zope , it ought to weigh in the balance. Then of course everyone is free to do development in their spare time. regards /JM ___ 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] Re: [Z3lab] Nuxeo supports Zope Corp announces
Eric Barroca wrote: Hello, Following the announces from Zope Corporation yesterday about their willingness to create a Zope Foundation (that would manage independently Zope 2 and Zope 3 projects) and to participate actively in the Z3ECM project, I would like to express briefly Nuxeo's position about all the news. First, we would like to thank Zope Corporation for Zope 2 and Zope 3 as Open Source software, they are amazing products ! For us as far as we know, the Zope Foundation is a really great news. This will probably solve the main issues we heard from people in the community and from some customers (brand and copyright security). It's really great news that Zope Corporation is now ready to go further on the community way and involvement. We are ready to help as much as needed in establishing the ZF as a vendor-neutral organisation with the mission to develop and promote a great technology (like the Apache or Eclipse Foundations). The Zope Foundation will, IOHO, a big step towards project 10X to establish Zope as a leading development platform for all kinds of web and internet applications. On the Z3ECM project, we are very glad that Zope Corporation wants to actively join the project ! We are certain that having ZC resources on this project will clearly help to build better products and solidify the platform. We will also support the move of the Z3ECM project to the ZF when the issues of copyright ownership will be discussed with the project stakeholders. It could definitely help unifying CMS zope community and will give more credibility to the platform from a customer point of view. We will also support the move of the Z3ECM project to the ZF when the issues of copyright ownership will be discussed with the project stakeholders In short, we are really happy and excited, and will definitely supports ZC to move forward on these topics with the other members of the Zope community. I'm pretty confident that the whole community will support this as well. Best regards, EB. -- ric Barroca, Tel: +33 6 21 74 77 64 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! www.nuxeo.com - www.cps-project.org - www.indesko.com Hi! This is really great news! I am going to start working at getting Chalmers to be one of the key players in the foundation which would make the foundation even more vendor-neutral. I am confident that this will go through. regards /JM ___ 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] zpt code crashes zope 2.7.3
Hi!
the following zpt snippet crashes zope 2.7.3 on Linux (the python
process hangs).
tal:block define=
items python: {u'\xc4': ''};
key python: u'\xc4'
content=items/?key /
can someone confirm that the bug is present in zope 2.7.4-b1 too before
I do a bug report?
regards /JM
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] zpt code crashes zope 2.7.3
Jean-Marc Orliaguet wrote:
Hi!
the following zpt snippet crashes zope 2.7.3 on Linux (the python
process hangs).
tal:block define=
items python: {u'\xc4': ''};
key python: u'\xc4'
content=items/?key /
can someone confirm that the bug is present in zope 2.7.4-b1 too
before I do a bug report?
regards /JM
OK it is reported as Issue 1617 in the zope bug collector (I tagged it
as confidential since the process sometimes dumps core)
regards /JM
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] zpt code crashes zope 2.7.3
Andreas Jung wrote:
--On Donnerstag, 9. Dezember 2004 13:12 Uhr +0100 Jean-Marc Orliaguet
[EMAIL PROTECTED] wrote:
Jean-Marc Orliaguet wrote:
Hi!
the following zpt snippet crashes zope 2.7.3 on Linux (the python
process hangs).
tal:block define=
items python: {u'\xc4': ''};
key python: u'\xc4'
content=items/?key /
can someone confirm that the bug is present in zope 2.7.4-b1 too
before I do a bug report?
regards /JM
OK it is reported as Issue 1617 in the zope bug collector (I tagged
it as
confidential since the process sometimes dumps core)
Since it is already on the list it is no longer
confidential...currently working on the issue..
-aj
OK so the solution right now is to await a new version of python or use
python 2.3.3
/JM
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
