[Zope] CPS 3.4.0 beta2 released + final bugday tomorrow
CPS 3.4.0 beta2 has been released yesterday. Tarballs/zipballs are available here: http://www.cps-project.org/static/src/CPS-3.4.0beta2.tar.gz http://www.cps-project.org/static/src/CPS-3.4.0beta2.zip We're planning a final release next week (after the CMF 1.6.0 release which is planned for Sunday, February 26th 2006: http://www.zope.org/Products/CMF/CMF-1.6.0-beta/News_Item.2006-02-19.5839). We're also having a bugday tomorrow, wednesday 02/22/2006, on IRC channel #cps on freenet, to sort out and fix the outstanding issues: http://svn.nuxeo.org/trac/pub/query?status=newstatus=assignedstatus=reopenedmilestone=CPS%203.4.0 You may also discuss your issues with this beta on the cps-devel mailing list (http://lists.nuxeo.com/mailman/listinfo/cps-devel). About CPS: Nuxeo CPS (version 3) is an open source, GPL-licensed framework designed for building content management, collaboration and business processing applications. It addresses the needs of web applications developers to easily create rich document types, with workflow-based access control, portal-like interfaces for accessing documents and information, and rich services that match the features of best of breed non-free (proprietary) offering in the domain, including: single-sourcing, versioning, indexing, metadata management, localization and translation, notifications, commenting, theming (user interface customization), users and groups directories, content scheduling and staging, syndication... Higher level components, including mail, calendaring and discussion applications, have been developed on top of the base framework, as well as custom business applications featuring complex document types and workflows. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
Andrew Milton wrote: +---[ Philipp von Weitershausen ]-- | Andrew Milton wrote: | +---[ Stephan Richter ]-- | | Hello everyone, | | | | With the development of Zope 3, the Zope developers committed to a new | | development process and higher software quality guidelines. With the adoption | | of Zope 3 technologies in the wider Zope community, we should also start | | using the process for third party package development. | | | | I have spent the last two weeks working on a proposal that defines a Zope | | Software Certification Program (ZSCP) and a Common Repository that implements | | this process. The proposal is attached to this mail. I welcome any comments | | about it! | | So in order to even get your Open Source package LISTED, you have to sign over | the rights of your code to Zope Corp (currently, Zope Foundation later), and then | check it into the svn respository. | | Is this is correct? | | No. The common repository under the wings of ZC/ZF is just *a* | repository that implements the ZSCP. There can be others, for example | the Plone repository, the collective repository (perhaps), etc. block quote The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team. ^^^ Code in the Common Repository *must* also use the license stated in section 3.5 and developers *must* sign the contributor agreement. The ^ agreement is necessary to ensure that contributions originated from the contributing developer. /end quote a) Supported by Zope development team b) Must sign contributor agreement. I don't see why a 'repository' of 3rd party packages needs any agreement signed, unless some kind of indemnity is required which it wouldn't need if it's just a repository. Any 'infringement' would simply result in the offending code being removed from the repository (which would have to happen anyway in case someone 'lied' about owning it). After all the repository is not claiming ownership of the code is it (unless you have to sign it over) The license for the code should also be irrelevant, since it's just a repository right? Just a convenient one stop shop for packages. So each package should be able to have its own license, no need for a common license. Having to sign the agreement serves no purpose unless there's some other IP issue involved other than simply storing the code. Handing over ownership to the ZF and therefore having signed a Contributor Agreement are the terms of the svn.zope.org repository, just like that code is to be made ZPL. These are the rules of the repository, even today (except for s/ZF/ZC). If you're not happy with that, then use your another repository. Nobody is forcing you to put your stuff there. Putting stuff into svn.zope.org *does* have advantages: * it's easy to feed packages upstream to Zope for a later inclusion into a Zope distribution. * putting a project/package under the wings of the ZF ensures long-term IP protection * code in svn.zope.org will be under the common control of the Zope developers which makes long-term maintenance easier to ensure. * the common license (ZPL) and the common ownership of the ZF do away with some legal headaches... Perhaps there are others. Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] help
Andreas Pakulat wrote: This should show at least zope-2.7. If that shows up you can find the documentation and how to setup an instance in /usr/share/doc/zope-2.7. Although, in all seriousness, I'd recommend installing from source. And I'd recommend the original poster read Eric Raymond's how to ask questions post, 'help' is not a useful subject line... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] LocalFS problem
Fernando Martins wrote: I'm using LocalFS 1.7rc? and Zope 2.8.? in a Suse system. More importantly for this case, zope is behind Apache 1.39 with module NTLM, What are you using to do NTLM? through FastCGI, Why on earth would you inflict this on yourself? ;-) When I access a file in a LocalFS folder I get the following info, instead of the pdf file (in this case): open file '/work/docs/MyFile.PDF', mode 'rb' at 0x42310974. What's the code and urls you're using to access this? The LocalFS folder accessed in the past through Apache+mod_rewrite without NTLM+RemoteUserFolder used to work fine. Interesting... So, the combination Apache+NTLM+FastCGI+RemoteUserFolder with LocalFS isn't working well. My guess would be RemoteUserFolder is the cuplrit. What is this RemoteUserFolder and where did you get it from? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Poskey Errors and BTreeFolder
Anton Stonor wrote:
Right, I just thought that made little sence when it came to Poskey Errors.
There are reasons why we ask for these things...
Zope 2.7.8, Plone 2.0.5. Tracebacks such as:
2005-12-09T18:46:04 ERROR(200) ZODB Couldn't load state for 0x04b364
Traceback (most recent call last):
File /var/www/zope/2.7.8/lib/python/ZODB/Connection.py, line 597, in
setstate
p, serial = self._storage.load(oid, self._version)
File /var/www/zope/2.7.8/lib/python/ZEO/ClientStorage.py, line 757,
in load
p, s, v, pv, sv = self._server.zeoLoad(oid)
File /var/www/zope/2.7.8/lib/python/ZEO/ServerStub.py, line 82, in
zeoLoad
return self.rpc.call('zeoLoad', oid)
File /var/www/zope/2.7.8/lib/python/ZEO/zrpc/connection.py, line
489, in call
raise inst # error raised by server
POSKeyError: 0x04b364
This is an error from the ZEO client. Can you have a look in your
storage server's log and find the corresponding error (match the
date/time). It'll hopefully hold some more clues...
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] unbuffered response.write through Apache 2.0 reverse proxy?
Christoph Berendes wrote: so I've padded this with blanks to hit the buffer size. Klugey,but works. Any reason why you don't just lower the buffer size? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Double quote in ZSQL Method
Andrew Milton wrote: | In a ZSQL Method, I have tablename.dtml-sqlvar species type=string | and I get tablename.'species_value', what I need is | tablename.species_value. Any idea how I can get Zope/ZSQL to not | put in the single quotes (or use double quotes)? | tablename.dtml-var species Don't use sqlvar except for things you want quoted.. use dtml-var Surely with this he won't get _any_ quotes? The guy's after double quotes for some unfathomable reason ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] image processing site quidance...
Tino Wildenhain wrote: Nicolas Georgakopoulos schrieb: Hello Zopistas, I need a little guidance for a site that must make image processing on the fly. Users should be able to upload image files and after some pixels manipulation they should see the image preview after the changes and download it. You should be much more precise about what some pixels manipulation actually means :-) Writing a drawing program is not so easy I think. Maybe with more client side intelligence... It will not be some kind of drawing program , just some simple changes in the pixels values. I have installed PIL successfully for that reason (thanks to smiley Chris) so I can use it as an external method. For more then just a single convert (even then) I'd write a complete external product. Its much easier to test and install and can do more. I don't have any experience writing external products... should be easy if I finish the python programming part as a simple traditional python release and then to implement it as a Zope product ? I have thought to do this implementation uploading the file to the ZopeDB and change it there or should the file be uploaded in the local file system ? Actually depends on what you want to do and what you want to do after the changes. E.g. do you want to save a complete history of the manipulation? Then I'd go ZODB completely. If you dont want to save the image, I'd go tempfiles and pass the handles to them around the SESSION. (see tempfile module) Maybe a combination is apropriate. Saving the history of the image process actions it is not required. Saving the images ... maybe. I will check this tempfile module. either way , what should I know so I can do that ? You should experiment with PIL - maybe outside zope. Im am already experimenting with PIL in a python shell and learning PIL it is not my purpose of this mail ;-) You should learn how to write a simple python based product. Will check the Zope book for that.. You should read about ZODB programming so not to read whole image objects at once. For what part of my needs should I read about ZODB ? Can't understand the not to read whole image objects at once cheers.. begin:vcard fn:Nicolas Georgakopoulos n:Georgakopoulos;Nicolas email;internet:[EMAIL PROTECTED] tel;work:2810 391945 tel;fax:2810 391937 tel;cell:6945 714 578 version:2.1 end:vcard ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Poskey Errors and BTreeFolder
Chris Withers wrote: This is an error from the ZEO client. Can you have a look in your storage server's log and find the corresponding error (match the date/time). It'll hopefully hold some more clues... It must be this one: 2005-12-09T18:46:04 INFO(0) zrpc-conn(S):127.0.0.1:33828 zeoLoad() raised exception: 0x04b364 Traceback (most recent call last): File /var/www/zope/2.7.8/lib/python/ZEO/zrpc/connection.py, line 373, in handle_request ret = meth(*args) File /var/www/zope/2.7.8/lib/python/ZEO/StorageServer.py, line 240, in zeoLoad v = self.storage.modifiedInVersion(oid) File /var/www/zope/2.7.8/lib/python/ZODB/FileStorage.py, line 743, in modifiedInVersion raise POSKeyError(oid) POSKeyError: 0x04b364 The traceback pattern is the same in all the zeo.log poskeyerror messages--just different oids. /Anton ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
+---[ Philipp von Weitershausen ]-- | | Handing over ownership to the ZF and therefore having signed a | Contributor Agreement are the terms of the svn.zope.org repository, just | like that code is to be made ZPL. The license part is irrelevant after you've signed over the IP. | These are the rules of the repository, even today (except for s/ZF/ZC). This is for the core product. This is not add-on code. It makes sense for the core product. | If you're not happy with that, then use | your another repository. Nobody is forcing you to put your stuff there. Indeed. Anyone that wants to try is welcome to come around and have a go d8) | Putting stuff into svn.zope.org *does* have advantages: | | * it's easy to feed packages upstream to Zope for a later inclusion into | a Zope distribution. Putting into svn isn't the same as requiring IP handover. You can still put things into the repository without IP handover. | * putting a project/package under the wings of the ZF ensures long-term | IP protection How? I think my death + 70 years is further away than the death of ZF, or in fact the death of Zope. | * code in svn.zope.org will be under the common control of the Zope | developers which makes long-term maintenance easier to ensure. This has nothing to do with handing over IP either. Noone disputes that the Zope Developers lives will be easier if things are in a central svn. Why this should require someone to hand over their IP to ZF is a mystery. | * the common license (ZPL) and the common ownership of the ZF do away | with some legal headaches... The ONLY legal headache common ownership does away with, is that ZC or ZF (or future owners) are free to change the license without asking permission of the original author. The license itself is irrelevant, it doesn't apply to the copyright holder. IP sharing certainly has no advantages to the original author. Any lawsuit arising from some problem with the code would almost certainly name all stakeholders. Repository of 3rd party code? Great Idea. Packaging standards? Great Idea. Compliance Rating? Great Idea. Requiring IP Handover? Makes a mockery of the Open Source movement. Why should Mark Shuttleworth who has plenty of means, hand over IP for (parts of) SchoolTool? I'm sure he has more than enough ways to protect his IP. Or are you saying that it makes sense for ZF/ZC to protect him? As I say, IP handover makes sense for the core product, but, doesn't make sense for 3rd party code, which is after all 3RD PARTY code. -- Andrew Milton [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Double quote in ZSQL Method
+---[ Chris Withers ]-- | Andrew Milton wrote: | | In a ZSQL Method, I have tablename.dtml-sqlvar species type=string | | and I get tablename.'species_value', what I need is | | tablename.species_value. Any idea how I can get Zope/ZSQL to not | | put in the single quotes (or use double quotes)? | | | | tablename.dtml-var species | | Don't use sqlvar except for things you want quoted.. use dtml-var | | Surely with this he won't get _any_ quotes? The guy's after double | quotes for some unfathomable reason ;-) Well he said no quotes OR double quotes I didn't think I'd need the sock puppets for him to work out how to get the double quotes d8) -- Andrew Milton [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Double quote in ZSQL Method
Jason C. Leach In a ZSQL Method, I have tablename.dtml-sqlvar species type=string and I get tablename.'species_value', what I need is tablename.species_value. Any idea how I can get Zope/ZSQL to not put in the single quotes (or use double quotes)? dtml-var species sql_quote JL. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
Andrew Milton wrote: +---[ Philipp von Weitershausen ]-- | | Handing over ownership to the ZF and therefore having signed a | Contributor Agreement are the terms of the svn.zope.org repository, just | like that code is to be made ZPL. The license part is irrelevant after you've signed over the IP. | These are the rules of the repository, even today (except for s/ZF/ZC). This is for the core product. This is not add-on code. It makes sense for the core product. | If you're not happy with that, then use | your another repository. Nobody is forcing you to put your stuff there. Indeed. Anyone that wants to try is welcome to come around and have a go d8) FWIW, Martijn and I did this with the z3base (http://codespeak.net/z3). | Putting stuff into svn.zope.org *does* have advantages: | | * it's easy to feed packages upstream to Zope for a later inclusion into | a Zope distribution. Putting into svn isn't the same as requiring IP handover. You can still put things into the repository without IP handover. | * putting a project/package under the wings of the ZF ensures long-term | IP protection How? I think my death + 70 years is further away than the death of ZF, or in fact the death of Zope. But the end of your commitment to this particular software and/or Zope might not be so far. Hunting developers down for getting their approval of a license change or something like that after 5 years or so would be a considerable pain. | * code in svn.zope.org will be under the common control of the Zope | developers which makes long-term maintenance easier to ensure. This has nothing to do with handing over IP either. Noone disputes that the Zope Developers lives will be easier if things are in a central svn. Why this should require someone to hand over their IP to ZF is a mystery. I never said the advantages of putting stuff into svn.zope.org necessarily have to have anything to do with handing over IP (actually, it's joint-ownership so it's sharing IP). | * the common license (ZPL) and the common ownership of the ZF do away | with some legal headaches... The ONLY legal headache common ownership does away with, is that ZC or ZF (or future owners) are free to change the license without asking permission of the original author. The license itself is irrelevant, it doesn't apply to the copyright holder. IP sharing certainly has no advantages to the original author. Any lawsuit arising from some problem with the code would almost certainly name all stakeholders. Repository of 3rd party code? Great Idea. Packaging standards? Great Idea. Compliance Rating? Great Idea. Requiring IP Handover? Makes a mockery of the Open Source movement. Plone does it, ASF does it, FSF does it. Seems to work. Note that with ZC (and I presume this will continue with the ZF) it's joint-ownership, not a total handover. Why should Mark Shuttleworth who has plenty of means, hand over IP for (parts of) SchoolTool? Good question. Why would Zope Corporation hand over IP of Zope to the Zope Foundation? Why would we contribute code to the Plone Foundation or anyone else? In order to put the code under public govenance. Anyways, you're welcome to contribute code to the z3base if you'd prefer a public repository that doesn't require IP handover/sharing. Who knows, perhaps we'll even manage to implement the ZSCP for some packages there :). Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-Users] Re: The Zope Software Certification Program and Common Repository Proposal
Philipp von Weitershausen wrote: Andrew Milton wrote: +---[ Stephan Richter ]-- | Hello everyone, | | With the development of Zope 3, the Zope developers committed to a new | development process and higher software quality guidelines. With the adoption | of Zope 3 technologies in the wider Zope community, we should also start | using the process for third party package development. | | I have spent the last two weeks working on a proposal that defines a Zope | Software Certification Program (ZSCP) and a Common Repository that implements | this process. The proposal is attached to this mail. I welcome any comments | about it! So in order to even get your Open Source package LISTED, you have to sign over the rights of your code to Zope Corp (currently, Zope Foundation later), and then check it into the svn respository. Is this is correct? No. The common repository under the wings of ZC/ZF is just *a* repository that implements the ZSCP. There can be others, for example the Plone repository, the collective repository (perhaps), etc. I had earlier suggested to Stephan that we should keep the common repository separate from ZSCP and there out of this proposal. IMO there should be a separate proposal for the common repository. I guess he didn't agree. I think both the ZSCP and the common repository (in the context of the ZF) are a great idea. We should try to have as much stuff as possible in the common repository, but we shouldn't make the process dependent on it. I'm therefore still suggesting to divide up the proposal. +1 I specially like the ZSCP proposal. It is very similar to a project we are involved in, the EDOS project (www.edos-project.org). I strongly believe that it is a perfect match for the whole idea of having a component architecture in the first place. I also like the common repository idea, if it can provide the same level of QA functions we currently have at nuxeo (trac.nuxeo.org + buildbot.nuxeo.org), though I fear that Trac can't scale well to a project spanning several important subprojects (here scaling means providing both global views and by-project views of what's going on). However, I believe like you Philipp, that both initiatives should be decoupled. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
+---[ Philipp von Weitershausen ]-- | | | * putting a project/package under the wings of the ZF ensures long-term | | IP protection | | How? I think my death + 70 years is further away than the death of ZF, or in | fact the death of Zope. | | But the end of your commitment to this particular software and/or Zope | might not be so far. Hunting developers down for getting their approval | of a license change or something like that after 5 years or so would be | a considerable pain. One wonders, why you NEED to change the license of someone else's code. You take some Open Source code. You put it in your repository where you can work on it. You don't need to own it to work on it. You don't need to own it to package it up. You don't need to own it to put it into svn. This is of course a distraction from the main question about the repository, not the who owns what and why, which has been beaten to death in a hundred other discussions. | Requiring IP Handover? Makes a mockery of the Open Source movement. | | Plone does it, ASF does it, FSF does it. Seems to work. The proposal currently requires 3rd party code to be handed over to Zope Foundation[1] AND checked into the ZF svn repository in order to be 'certified'. You indicated this was indeed the case. So in order to gain ANY level of certification, even Listed Zope Foundation has to own the code. If Zope Foundation actually owns the code it's no longer 3rd party code is it? It is therefore impossible for anyone outside of Zope Foundation to actually gain certification. Gaining certification is pointless (to an author), since making changes to code that's not in the zope svn repository, would obviously have to void the certification (being in the zope svn repository is a necessary, (but not sufficient) part of being certified). So once again, I think another kind of compliance programme would be far more beneficial for the majority of Zope Users. Once again this could to a certain level be achieved by having packaging tools to ensure that ANY code released WOULD be able to gain at least LISTED level IF they had given it to ZF AND checked it into the repository. Yes like a .jar file (OK we all know they're zip files with some fluff, that doesn't make them bad). [1] Let's just assume Zope Foundation for the purposes of this discussion. -- Andrew Milton [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
Andrew Milton wrote: +---[ Philipp von Weitershausen ]-- | | | * putting a project/package under the wings of the ZF ensures long-term | | IP protection | | How? I think my death + 70 years is further away than the death of ZF, or in | fact the death of Zope. | | But the end of your commitment to this particular software and/or Zope | might not be so far. Hunting developers down for getting their approval | of a license change or something like that after 5 years or so would be | a considerable pain. One wonders, why you NEED to change the license of someone else's code. You take some Open Source code. You put it in your repository where you can work on it. You don't need to own it to work on it. You don't need to own it to package it up. You don't need to own it to put it into svn. This is of course a distraction from the main question about the repository, not the who owns what and why, which has been beaten to death in a hundred other discussions. So let's not further discuss a dead point :). | Requiring IP Handover? Makes a mockery of the Open Source movement. | | Plone does it, ASF does it, FSF does it. Seems to work. The proposal currently requires 3rd party code to be handed over to Zope Foundation[1] AND checked into the ZF svn repository in order to be 'certified'. You indicated this was indeed the case. I did absolutely not. In the very first email in this thread, you asked whether the requirement for getting your package listed (or certified for that matter) was to put the code into svn.zope.org. Here's what I responded: No. The common repository under the wings of ZC/ZF is just *a* repository that implements the ZSCP. There can be others, for example the Plone repository, the collective repository (perhaps), etc. In fact, because of that I suggested to keep the repository proposal separate from the ZSCP proposal, as the very same email continues: I had earlier suggested to Stephan that we should keep the common repository separate from ZSCP and there out of this proposal. IMO there should be a separate proposal for the common repository. I guess he didn't agree. So in order to gain ANY level of certification, even Listed Zope Foundation has to own the code. Wrong. Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
I seem to have confused myself with the replies. Check into Repository not required for Certification. -- Andrew Milton [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
+---[ Philipp von Weitershausen ]-- | | The proposal currently requires 3rd party code to be handed over to Zope | Foundation[1] AND checked into the ZF svn repository in order to be | 'certified'. You indicated this was indeed the case. | | I did absolutely not. In the very first email in this thread, you asked | whether the requirement for getting your package listed (or certified | for that matter) was to put the code into svn.zope.org. Here's what I | responded: | | No. The common repository under the wings of ZC/ZF is just *a* | repository that implements the ZSCP. There can be others, for example | the Plone repository, the collective repository (perhaps), etc. Right, but, surely not just anyone can operate their own ZSCP. They can follow the standards, but, they can't be self-certifying, this is where I got confused with your reply. -- Andrew Milton [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] ZODB Could not import class 'myAdMan' from module '*OEpEfZxd1Zzml/FOi4fDrA=='
Haj, myBannerProduct 1.0 won´t install properly on Zope 2.7.4/SuSE9.3. After untar and Restart of Zope there is only an empty myBannerProduct Folder in Installed Products. Additionally at de-install of the corrupt Product i get this: ZODB Could not import class 'myAdMan' from module '*OEpEfZxd1Zzml/FOi4fDrA==' TIA for any Hints and Suggestions im ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-dev] Re: The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 19:24, Martin Aspeli wrote: My immediate concern is about resources: Who will have the time or incentive to police the common repository and grant certification? It seems to be a non-trivial process that may end up being quite time-consuming. It may be perceived as too much red tape. Please read section 2.8 carefully. Here is the most relevant part: Both, the requirements and process, are developed in a way that it should be also simple and fast to receive certification level 1 and level 2. The turn-around time of a request for being granted a certification level 1 or level 2 should be about 1 day. The certification of level 3 will usually take some more time, since it requires the certification manager to inspect the code in much more detail. However, the certification time should not exceed a couple of weeks. Overall, it is very important for the process to have as little overhead as possible and make the certification process a quick, easy and fun experience. It may be perceived as too much centralised control, especially around licensing. In the sense that the Zope Foundation is giving out the certifications, yes, it is centralized. But this is necessary, to make the process seem valuable/legitimate. All other certifications are centralized too, such as the TÜV controls the C2 security certification process. In terms of license, the ZSCP makes no assumptions. Even commercial projects can be certified if they show a certification manager their code. All of section 2 does not talk about a required license. A particular license will only be asserted on the Common Repository, like the ZPL is now for svn.zope.org or the GPL for the Plone core. Secondly, and partly because I'm expecting this to come up in my absence: your proposal is eerily simlar to Alan's two-level Plone collective post to plone-dev, about having an approved list of contributors and packages in a fenced-off repository, in addition to the collective. Yes, I am surprised he posted that. He was on the pre-proposal committee and knew for a while this was coming. As you can see in Appendix 3, there were several Plone developers involved in the recent discussion. One obvious parallel here, by the way, is with the svn.plone.org/plone repository. That one is controlled by the Plone Foundation, requires a contributor agreement, and imposes restrictions on license and quality (albeit not as formally as you do). I think this is possibly a more valid comparison than with the Collective. Yeah, probably. As far as I understand the Goldegg protocol, the goal is to develop generic components that could be under a different license. So ideally I would like to have those components live in the Common Repository, but they do not have to. I have mentioned that at various places in the repository. I'm actually +1 on your proposal in spirit (if it can be shown to work, and if there is a broad consensus in the community to support it - in fact, this is important: if there is too much division, the proposal would likely be self-defeating) and -1 on his. Great! I agree with your reservation; but we have to try and from the comments I got from the pre-proposal committee (which represent a wide range of Zope sub-communities) I was encouraged that we would find a general agreement. snip discussion on Plone versus Zope 3 development eltism and a raised bar to entry. I think that balance is different in Plone than it is in Zope 3. Yes, I agree. Thus the proposal clearly states in section 3.2: The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team. Put differently, I think that *some* Plone components ought to move lower down the stack, target re-usability in different systems, and thus be subject to somewhat different rules. Perhaps these components shouldn't have been Plone components in the first place, or perhaps their evolution would start in Plone and move down the stack. But I think it would be damaging for the Plone community, given its current shape and culture, to impose those rules across the types of components that are higher up the stack - arguably those components which should be Plone components still. I would never try to do this. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 20:09, Andrew Milton wrote: So in order to even get your Open Source package LISTED, you have to sign over the rights of your code to Zope Corp (currently, Zope Foundation later), and then check it into the svn respository. Is this is correct? NO! ABSOLUTELY NOT! The ZSCP is totally disconnected from the Common Repository. Note that the ZSCP does not talk about any repositories or technical implementation. It only talks about the certification goals, requirements and data. So you're proposing that the Zope Foundation will not even mention other Open Source code that isn't actually owned and controlled by the Zope Foundation? Huh? Where did you get this idea from? Did you actually read the proposal? Having a standard Zope package format would be far far more useful to the users at large, along with the associated tools (so developers can create compliant zope packages, and users can install packages actually using Zope). Packaging tools can then enforce certain restrictions automatically and create a manifest. We cannot require something that we do not have. Thus I did not address packaging or strong dependency meta-data in the proposal. I think once we investigated eggs and have some initial implementation, the proposal will be updated in light of this. If you had that, then that would certainly ease adding 'stuff' to the 'certified' repository, getting to LISTED level would be automatic. Becoming listed will be a nearly automated process. Also receiving level 1 and 2 will be quick decisions. This is clearly stated in section 2.8. I have added a questions to the QA section clearly stating that the ZSCP does not require packages in the Common Repository. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 23:16, Philipp von Weitershausen wrote: No. The common repository under the wings of ZC/ZF is just *a* repository that implements the ZSCP. There can be others, for example the Plone repository, the collective repository (perhaps), etc. Correct. I had earlier suggested to Stephan that we should keep the common repository separate from ZSCP and there out of this proposal. IMO there should be a separate proposal for the common repository. I guess he didn't agree. I did agree that the two were too intermingled and thus clearly separated them. However, I personally do not have the resources to push two separate proposals on this, since I think the two are so closely related; in fact at the beginning I thought of them as one. If the common repository would not be part of the proposal, I would feel that people would dismiss it as nice to have, but it ain't gonna happen. It is very important to me that we will be able to implement the process quickly and get on our way certifying packages. I think both the ZSCP and the common repository (in the context of the ZF) are a great idea. We should try to have as much stuff as possible in the common repository, but we shouldn't make the process dependent on it. Correct. The latest revision clearly separates the two. To show their independence, I have (a) placed the two subjects into two separate main sections, (b) made sure that none of section 2 (ZSCP) requires anything from section 3 (the repository), and (c) made sure that the process does not depend on Open Source licenses or information that would only be known in public projects. I have spent a lot of time trying to be *very careful* rereading the sections over and over again. If you find that anything in the document contradicts those 3 points above, let me know! I am very interested in fixing those type of bugs! :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 23:55, Andrew Milton wrote: Wow, you took the following two quotes out of context. block quote The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team. ^^^ This is from section 2, which defines the ZSCP. Code in the Common Repository *must* also use the license stated in section 3.5 and developers *must* sign the contributor agreement. The ^ agreement is necessary to ensure that contributions originated from the contributing developer. /end quote This is from section 3, which defines *one possible implementation* of the ZSCP. But I see where your confusion stems from and I have added a paragraph to section 3.1 stating that the Common Repository is one implementation of the ZSCP but not the only one: The Common Repository is only *one* implementation of the ZSCP. While the Common Repository implements the ZSCP guidelines and suggested automation tools, the ZSCP process itself does *not* require the Common Repository. The license for the code should also be irrelevant, since it's just a repository right? Just a convenient one stop shop for packages. So each package should be able to have its own license, no need for a common license. For the ZSCP, the license is irrelevant. For the Common repository it is not. Having to sign the agreement serves no purpose unless there's some other IP issue involved other than simply storing the code. The following does *not* concern the ZSCP, but the code and repository: Right, the other issue is upstream movement. Let's say you have a package that has many contributors, like zope.interface, and the Python developers would like to put the interface package into the Python standard library. Since zope.interface is ZPL and Python has its license, you need to change that. If you do not have a contributor agreement that assigns half of the rights to an organization, then you have to ask *all* developers whether the license change is okay. If you cannot find a developer anymore you can never change that license. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 03:57, Philipp von Weitershausen wrote: Putting stuff into svn.zope.org *does* have advantages: * it's easy to feed packages upstream to Zope for a later inclusion into a Zope distribution. * putting a project/package under the wings of the ZF ensures long-term IP protection * code in svn.zope.org will be under the common control of the Zope developers which makes long-term maintenance easier to ensure. * the common license (ZPL) and the common ownership of the ZF do away with some legal headaches... Very good summary. Better than mine. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
snip IP discussion Okay, this discussion is off-topic. I will not respond to it, unless I read about something that relates directly to the proposal. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Five defaultView and REQUEST.URL0
Hi I've created simple view that just displays few lines of text (with national characters) and URL of the current page (which is received by call to my product method (code below)). I'm using UTF-8. I've used REQUEST.URL0 to generate url. The problem is when I'm accessing my object via it's name (I'mean when defaultView is used) like: http://localhost:8080/my_problem_object I get: 'ascii' codec can't decode byte 0xc4 in position 154: ordinal not in range(128) Suprisingly to me when I'm using: http://localhost:8080/my_problem_object/@@test_uni everything works correclty. Without national characters in Page Template it works OK. When I'm not using self.REQUEST.URL0 it works correctly too. When I use str(self.REQUEST.URL0) everything is good again. Can somebody tell me whether I'm doing something in a wrong way, or maybe it is a bug or feature? I dont understand why there is such a difference between view and default view? Below is a part of my code: ---main class--- class GeneralModule(Folder): GeneralModule (...) def get_obj_url(self): return self.REQUEST.URL0 (...) ---view is--- html xmlns=http://www.w3.org/1999/xhtml; lang=pl xml:lang=pl body h1 Some unicode characters here: łąka/h1 span tal:content=python: context.get_obj_url()/span /body /html ---configure.zcml:--- five:traversable class=.GeneralModule.GeneralModule / five:defaultViewable class=.GeneralModule.GeneralModule / browser:page for=.GeneralModule.IGeneralModule template=./zpt/test_uni.zpt name=test_uni permission=zope.Public / browser:defaultView for=.GeneralModule.IGeneralModule name=test_uni / ... -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-dev] The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:59, Reinoud van Leeuwen wrote: This seems to me a great step forward but I am missing something. The quality is measured by a number of metrics, but it seems nowhere is actually measured if the software does what it is supposed to do, if it is clear how it works and whether it is something you would advise other people to use. This is one of the major problems I've had in the past with things like the Perl CPAN repository: you can find lot's of modules that seem to solve your problem, but usually you discover what a module is really about when you've invested a lot of time in it. Right, I hear you. In fact, this is one of the reasons that we decided against a name like Zope Software Quality Program. With the proposed process, we cannot guarantee 100% that the package is good. However, there are a couple of safe guards: (1) If you write doctests as a narrative text file, you really have to think hard about the functionality your package provides. I cannot stress it enough, doctest text files are *key* to the success of the certification program. (2) At least in the Common Repository, people will read check-in messages. (3) At higher certification levels, other people must support the package. This is also not 100% bullet proof, but it is something. Overall, I also expect that the community has little tolerance for malicious attempts to break the system. If someone detects foul play all he has to do is complain on the mailing lists. Would there be room for a voting or feedback step in the process where people that have tried the module could enter a rating? Ah, rating and feedback. :-) This was discussed in the pre-proposal phase as well. The problem with feedback and rating is that to do it right, it requires a lot of resources that we do not have. Here is a scenario: 1. A user U trashes a package because an important feature F is missing in package P. So far so good. It is his right to do so. 2. The package P authors see the comment and fix it in the code. Very cool, the process works. 3. But then the user U of the post, must retract his comment. What if he is not available? Not so good. The alternative would be to ask a certification manager, who might know nothing about the issue and will need a lot of time reviewing the complaint and solution. Not so good. While rating and feedback is good, to do it right in a process like the ZSCP costs a lot of resources. Having said that, I see the need to address the issue. Here are two suggestions: 1. Add a Future Possibilities section to the proposal collecting ideas for later iterations of the process. This would allow us to address some of the common concerns and say: If we have time and resources, this can be done. 2. There is already a provision in the process that a package can receive a warning. Currently the ZSCP states that the warning can only be issued when a package does not fulfill the quality metrics for a given release. I could add another provision that a warning can be issued, if X community members and 1 certification manager verified a bad package. Each warning carries an arbitrary comment that could describe the reason of the warning. This way we can use the existing communication channels (mailing list and IRC) for feedback and still have a way to formalize feedback. I guess in this case we would also need a resolve action that could resolve a warning. What do you think? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-Users] Re: [Zope3-dev] The Zope Software Certification Program and Common Repository Proposal
I hate to cross-post this, but would it be possible to limit this discussion to a single list (e.g. zope3-dev, maybe)? I'm interested in this topic, but my mail client isn't smart enough to filter it out to only one place and I'm sure there are a lot of other people with the same issue. - C On Feb 21, 2006, at 9:45 AM, Stephan Richter wrote: On Tuesday 21 February 2006 05:59, Reinoud van Leeuwen wrote: This seems to me a great step forward but I am missing something. The quality is measured by a number of metrics, but it seems nowhere is actually measured if the software does what it is supposed to do, if it is clear how it works and whether it is something you would advise other people to use. This is one of the major problems I've had in the past with things like the Perl CPAN repository: you can find lot's of modules that seem to solve your problem, but usually you discover what a module is really about when you've invested a lot of time in it. Right, I hear you. In fact, this is one of the reasons that we decided against a name like Zope Software Quality Program. With the proposed process, we cannot guarantee 100% that the package is good. However, there are a couple of safe guards: (1) If you write doctests as a narrative text file, you really have to think hard about the functionality your package provides. I cannot stress it enough, doctest text files are *key* to the success of the certification program. (2) At least in the Common Repository, people will read check-in messages. (3) At higher certification levels, other people must support the package. This is also not 100% bullet proof, but it is something. Overall, I also expect that the community has little tolerance for malicious attempts to break the system. If someone detects foul play all he has to do is complain on the mailing lists. Would there be room for a voting or feedback step in the process where people that have tried the module could enter a rating? Ah, rating and feedback. :-) This was discussed in the pre-proposal phase as well. The problem with feedback and rating is that to do it right, it requires a lot of resources that we do not have. Here is a scenario: 1. A user U trashes a package because an important feature F is missing in package P. So far so good. It is his right to do so. 2. The package P authors see the comment and fix it in the code. Very cool, the process works. 3. But then the user U of the post, must retract his comment. What if he is not available? Not so good. The alternative would be to ask a certification manager, who might know nothing about the issue and will need a lot of time reviewing the complaint and solution. Not so good. While rating and feedback is good, to do it right in a process like the ZSCP costs a lot of resources. Having said that, I see the need to address the issue. Here are two suggestions: 1. Add a Future Possibilities section to the proposal collecting ideas for later iterations of the process. This would allow us to address some of the common concerns and say: If we have time and resources, this can be done. 2. There is already a provision in the process that a package can receive a warning. Currently the ZSCP states that the warning can only be issued when a package does not fulfill the quality metrics for a given release. I could add another provision that a warning can be issued, if X community members and 1 certification manager verified a bad package. Each warning carries an arbitrary comment that could describe the reason of the warning. This way we can use the existing communication channels (mailing list and IRC) for feedback and still have a way to formalize feedback. I guess in this case we would also need a resolve action that could resolve a warning. What do you think? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:13, Andrew Milton wrote: Why should Mark Shuttleworth who has plenty of means, hand over IP for (parts of) SchoolTool? I'm sure he has more than enough ways to protect his IP. Or are you saying that it makes sense for ZF/ZC to protect him? The reason the SchoolTool project would be interested in putting a couple packages in the common repository would be so they are moved into the Zope 3 core pr are part of the distribution. It would mean that the SchoolTool developers have to maintain less code. However, we do not need to put all of SchoolTool into the repository just to get certified. We can ask for certification with the SchoolTool code living in another repository. In fact, I think SchoolTool might be one of the first outside projects to gain certifications, since it is the only large project that I know of that fulfills the level 2 requirements (I think it could even get level 3). Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:30, Philipp von Weitershausen wrote: Anyways, you're welcome to contribute code to the z3base if you'd prefer a public repository that doesn't require IP handover/sharing. Who knows, perhaps we'll even manage to implement the ZSCP for some packages there :). That would be very cool! :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 07:15, Andrew Milton wrote: The proposal currently requires 3rd party code to be handed over to Zope Foundation[1] AND checked into the ZF svn repository in order to be 'certified'. You indicated this was indeed the case. That's not true. Phillip and I both negated this assertion. Where did you read this? The quotes you had earlier were totally out of context. Nothing in Section 2 requires anything of section 3. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-dev] Re: [Zope3-Users] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:38, Stefane Fermigier wrote: However, I believe like you Philipp, that both initiatives should be decoupled. The two things are decoupled as section 2 does not require section 3. I decided to leave it in the same document for several reasons: (1) Bandwidth. Discussing two proposals of this size separately requires a lot of time. (2) I fear that the ZSCP would be talked to death and stay dead. My experience in the Open Source world has shown that if something does not have practicality, it dies unless someone is getting paid. I am certainly not getting paid for this. By biggest interest here is to bring the sub-communities together and define communication means on the code level. (3) If the ZSCP is discussed in too much abstraction, it will distance itself from what we can and want to do. While writing I have always used the Common Repository as reality check. (4) If the two were talked about separately, I think we would go back and forth on what information and process is needed. Right now, with the Common Repository in mind, I know exactly that the steps of the ZSCP will work. Overall, once we have a general agreement, section 2 will be lifted out of the proposal anyways to represent the first set of rules for the ZSCP. This document is proposal not just the rules. BTW, I am sorry for the confusion. I should have documented this better. I know I had in the earlier version, but it must have got lost. I have now added a section right at the beginning of section to communicate the separation better. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-Users] Re: [Zope3-dev] The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 09:48, Chris McDonough wrote: I hate to cross-post this, but would it be possible to limit this discussion to a single list (e.g. zope3-dev, maybe)? I'm interested in this topic, but my mail client isn't smart enough to filter it out to only one place and I'm sure there are a lot of other people with the same issue. Sure, so if people are interested, the discussion will continue on zope3-dev. I only cross-posted this, so as many people are reached as possible. This is a very important proposal to the whole community. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] LocalFS problem
Hi Chris, Fernando Martins wrote: I'm using LocalFS 1.7rc? and Zope 2.8.? in a Suse system. More importantly for this case, zope is behind Apache 1.39 with module NTLM, What are you using to do NTLM? simply mod_ntlm. I'm following the procedure on this page to do single sign-on for my Intranet web site: http://diaryproducts.net/about/cms/zope_plone/zope_plone_sso_single_sign_on_ windows_domain The software used is also linked from there. through FastCGI, Why on earth would you inflict this on yourself? ;-) Because it is the only way to pass the Apache environmental variable REMOTE_USER to Zope. This variable is set by Apache after the NTLM authentication. I suppose PCGI is also possible, but I haven't tried it out. I'm well aware and concerned that FastCGI has become deprecated for lack of maintainer. I guess this will be a major upgrade obstacle for those doing Intranet single sign-on. Other than that I don't know of any concrete FastCGI problem. When I access a file in a LocalFS folder I get the following info, instead of the pdf file (in this case): open file '/work/docs/MyFile.PDF', mode 'rb' at 0x42310974. What's the code and urls you're using to access this? No code, I get this in the browser just with an url like this: http://mysite.intranet/docs/MyFile.PDF /mysite/docs is a LocalFS folder that maps to a (Linux) folder /work/docs. (/mysite is a zope folder invisible for the users, through some URL rewriting done in Apache) The LocalFS folder accessed in the past through Apache+mod_rewrite without NTLM+RemoteUserFolder used to work fine. Interesting... yes, it was after adding NTLM+FastCGI to Apache+Zope that I got the LocalFS problems. So, the combination Apache+NTLM+FastCGI+RemoteUserFolder with LocalFS isn't working well. My guess would be RemoteUserFolder is the cuplrit. What is this RemoteUserFolder and where did you get it from? Got it from http://www.zope.org/Members/djay/RemoteUserFolder although I don't follow your logic since RemoteUF works fine with the rest of zope. RUF doesn't do any real authentication, I guess, it simply adds the REMOTE_USER user to the user folder and lets zope know the user is authenticated. Simple job I guess. Cheers, Fernando cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Granting access by reading http headers (Consulting opportunity)
Did I ask if it accepted cookie? No, I asked if it accepts http basic auth. Care to answer my question? ;-) Yes. The Google Mini accepts http basic auth. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope3-dev] Re: [Zope3-Users] Re: The Zope Software Certification Program and Common Repository Proposal
Stephan Richter wrote: (2) I fear that the ZSCP would be talked to death and stay dead. My experience in the Open Source world has shown that if something does not have practicality, it dies unless someone is getting paid. I am certainly not getting paid for this. By biggest interest here is to bring the sub-communities together and define communication means on the code level. I don't think it will stay dead, because it is really exciting :) S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-Annce] CPS 3.4.0 beta2 released + final bugday tomorrow
CPS 3.4.0 beta2 has been released yesterday. Tarballs/zipballs are available here: http://www.cps-project.org/static/src/CPS-3.4.0beta2.tar.gz http://www.cps-project.org/static/src/CPS-3.4.0beta2.zip We're planning a final release next week (after the CMF 1.6.0 release which is planned for Sunday, February 26th 2006: http://www.zope.org/Products/CMF/CMF-1.6.0-beta/News_Item.2006-02-19.5839). We're also having a bugday tomorrow, wednesday 02/22/2006, on IRC channel #cps on freenet, to sort out and fix the outstanding issues: http://svn.nuxeo.org/trac/pub/query?status=newstatus=assignedstatus=reopenedmilestone=CPS%203.4.0 You may also discuss your issues with this beta on the cps-devel mailing list (http://lists.nuxeo.com/mailman/listinfo/cps-devel). About CPS: Nuxeo CPS (version 3) is an open source, GPL-licensed framework designed for building content management, collaboration and business processing applications. It addresses the needs of web applications developers to easily create rich document types, with workflow-based access control, portal-like interfaces for accessing documents and information, and rich services that match the features of best of breed non-free (proprietary) offering in the domain, including: single-sourcing, versioning, indexing, metadata management, localization and translation, notifications, commenting, theming (user interface customization), users and groups directories, content scheduling and staging, syndication... Higher level components, including mail, calendaring and discussion applications, have been developed on top of the base framework, as well as custom business applications featuring complex document types and workflows. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-Checkins] SVN: Zope/trunk/ - Collector #1819: fixed method signature of
Log message for revision 41720: - Collector #1819: fixed method signature of MountedObject.SimpleTrailblazer._construct() Changed: U Zope/trunk/doc/CHANGES.txt U Zope/trunk/lib/python/Products/ZODBMountPoint/MountedObject.py -=- Modified: Zope/trunk/doc/CHANGES.txt === --- Zope/trunk/doc/CHANGES.txt 2006-02-20 21:54:18 UTC (rev 41719) +++ Zope/trunk/doc/CHANGES.txt 2006-02-21 09:41:31 UTC (rev 41720) @@ -197,6 +197,9 @@ Bugs Fixed + - Collector #1819: fixed method signature of +MountedObject.SimpleTrailblazer._construct() + - Collector #2019: removed validateValue() from cAccessControl (already removed in former Zope versions from the AccessControl Python implementation) Modified: Zope/trunk/lib/python/Products/ZODBMountPoint/MountedObject.py === --- Zope/trunk/lib/python/Products/ZODBMountPoint/MountedObject.py 2006-02-20 21:54:18 UTC (rev 41719) +++ Zope/trunk/lib/python/Products/ZODBMountPoint/MountedObject.py 2006-02-21 09:41:31 UTC (rev 41720) @@ -52,7 +52,7 @@ def __init__(self, base): self.base = base -def _construct(self, context, id, final): +def _construct(self, context, id): Creates and returns the named folder. dispatcher = guarded_getattr(context, 'manage_addProduct')['OFSP'] factory = guarded_getattr(dispatcher, 'manage_addFolder') ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.9/ - Collector #1819: fixed signature of
Log message for revision 41721: - Collector #1819: fixed signature of MountedObject.SimpleTrailblazer._construct() Changed: U Zope/branches/2.9/doc/CHANGES.txt U Zope/branches/2.9/lib/python/Products/ZODBMountPoint/MountedObject.py -=- Modified: Zope/branches/2.9/doc/CHANGES.txt === --- Zope/branches/2.9/doc/CHANGES.txt 2006-02-21 09:41:31 UTC (rev 41720) +++ Zope/branches/2.9/doc/CHANGES.txt 2006-02-21 09:42:49 UTC (rev 41721) @@ -18,6 +18,9 @@ Bugs fixed + - Collector #1819: fixed signature of +MountedObject.SimpleTrailblazer._construct() + - Collector #2019: removed validateValue() from cAccessControl (already removed in former Zope versions from the AccessControl Python implementation) Modified: Zope/branches/2.9/lib/python/Products/ZODBMountPoint/MountedObject.py === --- Zope/branches/2.9/lib/python/Products/ZODBMountPoint/MountedObject.py 2006-02-21 09:41:31 UTC (rev 41720) +++ Zope/branches/2.9/lib/python/Products/ZODBMountPoint/MountedObject.py 2006-02-21 09:42:49 UTC (rev 41721) @@ -52,7 +52,7 @@ def __init__(self, base): self.base = base -def _construct(self, context, id, final): +def _construct(self, context, id): Creates and returns the named folder. dispatcher = guarded_getattr(context, 'manage_addProduct')['OFSP'] factory = guarded_getattr(dispatcher, 'manage_addFolder') ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
Andrew Milton wrote: +---[ Philipp von Weitershausen ]-- | Andrew Milton wrote: | +---[ Stephan Richter ]-- | | Hello everyone, | | | | With the development of Zope 3, the Zope developers committed to a new | | development process and higher software quality guidelines. With the adoption | | of Zope 3 technologies in the wider Zope community, we should also start | | using the process for third party package development. | | | | I have spent the last two weeks working on a proposal that defines a Zope | | Software Certification Program (ZSCP) and a Common Repository that implements | | this process. The proposal is attached to this mail. I welcome any comments | | about it! | | So in order to even get your Open Source package LISTED, you have to sign over | the rights of your code to Zope Corp (currently, Zope Foundation later), and then | check it into the svn respository. | | Is this is correct? | | No. The common repository under the wings of ZC/ZF is just *a* | repository that implements the ZSCP. There can be others, for example | the Plone repository, the collective repository (perhaps), etc. block quote The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team. ^^^ Code in the Common Repository *must* also use the license stated in section 3.5 and developers *must* sign the contributor agreement. The ^ agreement is necessary to ensure that contributions originated from the contributing developer. /end quote a) Supported by Zope development team b) Must sign contributor agreement. I don't see why a 'repository' of 3rd party packages needs any agreement signed, unless some kind of indemnity is required which it wouldn't need if it's just a repository. Any 'infringement' would simply result in the offending code being removed from the repository (which would have to happen anyway in case someone 'lied' about owning it). After all the repository is not claiming ownership of the code is it (unless you have to sign it over) The license for the code should also be irrelevant, since it's just a repository right? Just a convenient one stop shop for packages. So each package should be able to have its own license, no need for a common license. Having to sign the agreement serves no purpose unless there's some other IP issue involved other than simply storing the code. Handing over ownership to the ZF and therefore having signed a Contributor Agreement are the terms of the svn.zope.org repository, just like that code is to be made ZPL. These are the rules of the repository, even today (except for s/ZF/ZC). If you're not happy with that, then use your another repository. Nobody is forcing you to put your stuff there. Putting stuff into svn.zope.org *does* have advantages: * it's easy to feed packages upstream to Zope for a later inclusion into a Zope distribution. * putting a project/package under the wings of the ZF ensures long-term IP protection * code in svn.zope.org will be under the common control of the Zope developers which makes long-term maintenance easier to ensure. * the common license (ZPL) and the common ownership of the ZF do away with some legal headaches... Perhaps there are others. Philipp ___ 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: [Zope3-dev] Re: merge zope-dev and zope3-dev?
Jim Fulton wrote: Only you and Philipp were excited about this. Not sure that constitutes a ringing endorsement. Maybe others will chime in now. I'm +10 too. I'd like to see this happen before the end of the year. Well, given that the majority are +/-0 and with the exception of one or two misguided individuals who seem to want Zope 3 to live on its own forever, how do we set a date? Why does this need to be a big deal? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] merge zope-dev and zope3-dev?
Fred Drake wrote: On 2/16/06, Chris Withers [EMAIL PROTECTED] wrote: To be clear: I'm talking _only_ about merging the dev lists, _not_ the user lists. The users lists are still largely independent, but it seems like just about every post to the dev list now has a bearing on both Zope 2 and Zope 3, especially as they become closer and closers... -1 Any particular reasons? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Zope 2.8.6 and 2.9.1 schedule
done --On 21. Februar 2006 08:00:47 +0100 robert rottermann [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 23. Januar 2006 21:37:10 +0100 Andreas Jung [EMAIL PROTECTED] wrote: I am plan to release Zope 2.8.6 and 2.9.1 in the middle of February (around Feb, 15th). Unfortunately I am currently too busy to do any releases right now. There are also some bug reports pending that should at least be checked before the next releases. I think I will have some time at or or after PyCon to care about the release. Andreas ___ 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 ) Andreas, could you please add a fix for http://www.zope.org/Collectors/Zope/1819 it is absolutely trivial and needs no testing (there is a stale parameter final on line 49 of Products/ZODBMountPoint/MountedObject.py) thanks robert pgpIu4dXhIWGo.pgp Description: PGP 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 )
[Zope-dev] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 3168 Blamelist: andreasjung,hdima,jim,oestermeier,shh,srichter,yuppie 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 )
[Zope-dev] Deprecating Zope 2 interfaces?
Hi there, I don't think it will make much sense to keep Zope 2 interfaces around for more than one year from now. In other words, I'm suggesting to deprecate them for Zope 2.10. There are a few places in Zope 2 where they are still used for checks (mostly webdav, OFS, ZCTextIndex). For the deprecation period, these checks will have to be done against both the Zope 2 and the Zope 3 interface. I think this is as hard as it gets for the switch-over to Zope 3 interfaces, but perhaps I'm missing something. Philipp ___ 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: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
Andrew Milton wrote: +---[ Philipp von Weitershausen ]-- | | Handing over ownership to the ZF and therefore having signed a | Contributor Agreement are the terms of the svn.zope.org repository, just | like that code is to be made ZPL. The license part is irrelevant after you've signed over the IP. | These are the rules of the repository, even today (except for s/ZF/ZC). This is for the core product. This is not add-on code. It makes sense for the core product. | If you're not happy with that, then use | your another repository. Nobody is forcing you to put your stuff there. Indeed. Anyone that wants to try is welcome to come around and have a go d8) FWIW, Martijn and I did this with the z3base (http://codespeak.net/z3). | Putting stuff into svn.zope.org *does* have advantages: | | * it's easy to feed packages upstream to Zope for a later inclusion into | a Zope distribution. Putting into svn isn't the same as requiring IP handover. You can still put things into the repository without IP handover. | * putting a project/package under the wings of the ZF ensures long-term | IP protection How? I think my death + 70 years is further away than the death of ZF, or in fact the death of Zope. But the end of your commitment to this particular software and/or Zope might not be so far. Hunting developers down for getting their approval of a license change or something like that after 5 years or so would be a considerable pain. | * code in svn.zope.org will be under the common control of the Zope | developers which makes long-term maintenance easier to ensure. This has nothing to do with handing over IP either. Noone disputes that the Zope Developers lives will be easier if things are in a central svn. Why this should require someone to hand over their IP to ZF is a mystery. I never said the advantages of putting stuff into svn.zope.org necessarily have to have anything to do with handing over IP (actually, it's joint-ownership so it's sharing IP). | * the common license (ZPL) and the common ownership of the ZF do away | with some legal headaches... The ONLY legal headache common ownership does away with, is that ZC or ZF (or future owners) are free to change the license without asking permission of the original author. The license itself is irrelevant, it doesn't apply to the copyright holder. IP sharing certainly has no advantages to the original author. Any lawsuit arising from some problem with the code would almost certainly name all stakeholders. Repository of 3rd party code? Great Idea. Packaging standards? Great Idea. Compliance Rating? Great Idea. Requiring IP Handover? Makes a mockery of the Open Source movement. Plone does it, ASF does it, FSF does it. Seems to work. Note that with ZC (and I presume this will continue with the ZF) it's joint-ownership, not a total handover. Why should Mark Shuttleworth who has plenty of means, hand over IP for (parts of) SchoolTool? Good question. Why would Zope Corporation hand over IP of Zope to the Zope Foundation? Why would we contribute code to the Plone Foundation or anyone else? In order to put the code under public govenance. Anyways, you're welcome to contribute code to the z3base if you'd prefer a public repository that doesn't require IP handover/sharing. Who knows, perhaps we'll even manage to implement the ZSCP for some packages there :). Philipp ___ 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-Users] Re: The Zope Software Certification Program and Common Repository Proposal
Philipp von Weitershausen wrote: Andrew Milton wrote: +---[ Stephan Richter ]-- | Hello everyone, | | With the development of Zope 3, the Zope developers committed to a new | development process and higher software quality guidelines. With the adoption | of Zope 3 technologies in the wider Zope community, we should also start | using the process for third party package development. | | I have spent the last two weeks working on a proposal that defines a Zope | Software Certification Program (ZSCP) and a Common Repository that implements | this process. The proposal is attached to this mail. I welcome any comments | about it! So in order to even get your Open Source package LISTED, you have to sign over the rights of your code to Zope Corp (currently, Zope Foundation later), and then check it into the svn respository. Is this is correct? No. The common repository under the wings of ZC/ZF is just *a* repository that implements the ZSCP. There can be others, for example the Plone repository, the collective repository (perhaps), etc. I had earlier suggested to Stephan that we should keep the common repository separate from ZSCP and there out of this proposal. IMO there should be a separate proposal for the common repository. I guess he didn't agree. I think both the ZSCP and the common repository (in the context of the ZF) are a great idea. We should try to have as much stuff as possible in the common repository, but we shouldn't make the process dependent on it. I'm therefore still suggesting to divide up the proposal. +1 I specially like the ZSCP proposal. It is very similar to a project we are involved in, the EDOS project (www.edos-project.org). I strongly believe that it is a perfect match for the whole idea of having a component architecture in the first place. I also like the common repository idea, if it can provide the same level of QA functions we currently have at nuxeo (trac.nuxeo.org + buildbot.nuxeo.org), though I fear that Trac can't scale well to a project spanning several important subprojects (here scaling means providing both global views and by-project views of what's going on). However, I believe like you Philipp, that both initiatives should be decoupled. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ 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: Deprecating Zope 2 interfaces?
Hi Philipp! Philipp von Weitershausen wrote: I don't think it will make much sense to keep Zope 2 interfaces around for more than one year from now. In other words, I'm suggesting to deprecate them for Zope 2.10. +10 But we can't deprecate z2 interfaces as long as Zope 2 itself uses them for other tasks than providing backwards compatibility. There are still some unconverted z2 interfaces in Zope 2. There are a few places in Zope 2 where they are still used for checks (mostly webdav, OFS, ZCTextIndex). In detail these are: 1.) WriteLock: Objects are only lockable if their class has WriteLockInterface in its __implements__ list. 2.) PluggableIndex: Indexes for ZCatalog have to be registered in Products.meta_types with PluggableIndexInterface. 3.) IFAwareObjectManager and the 'interfaces' argument of ObjectManager.all_meta_types: The mechanism used for pluggable indexes has a generic implementation in ObjectManager and can be used by any subclass of IFAwareObjectManager. For the deprecation period, these checks will have to be done against both the Zope 2 and the Zope 3 interface. In Zope 2.9 these mechanisms already work alternatively with z3 interfaces. There should be no need to use z2 interfaces in products written for Zope 2.9. I think this is as hard as it gets for the switch-over to Zope 3 interfaces, but perhaps I'm missing something. Don't think so. But there might be other z2 interfaces in use. Cheers, Yuppie ___ 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: Deprecating Zope 2 interfaces?
yuppie wrote: I don't think it will make much sense to keep Zope 2 interfaces around for more than one year from now. In other words, I'm suggesting to deprecate them for Zope 2.10. +10 But we can't deprecate z2 interfaces as long as Zope 2 itself uses them for other tasks than providing backwards compatibility. There are still some unconverted z2 interfaces in Zope 2. Right. These would have to be converted before or at the same time we introduce the deprecation. There are a few places in Zope 2 where they are still used for checks (mostly webdav, OFS, ZCTextIndex). In detail these are: 1.) WriteLock: Objects are only lockable if their class has WriteLockInterface in its __implements__ list. OFS.PropertySheets also does this. 2.) PluggableIndex: Indexes for ZCatalog have to be registered in Products.meta_types with PluggableIndexInterface. 3.) IFAwareObjectManager and the 'interfaces' argument of ObjectManager.all_meta_types: The mechanism used for pluggable indexes has a generic implementation in ObjectManager and can be used by any subclass of IFAwareObjectManager. Thanks for tracking those down. According to a search for 'isImplementedBy' (the old interface API method), there's also: 4) OFS.DTMLMethod and ZPublisher.HTTPResponse check for IStreamIterator 5) Products.Trancience checks for TransientItemContainer (no leading I) We should put #BBB comments to all of those locations so we won't forget. For the deprecation period, these checks will have to be done against both the Zope 2 and the Zope 3 interface. In Zope 2.9 these mechanisms already work alternatively with z3 interfaces. Not all of them but most of them. I think this is as hard as it gets for the switch-over to Zope 3 interfaces, but perhaps I'm missing something. Don't think so. But there might be other z2 interfaces in use. Sure, which is why we have the deprecation period for 12 months after the Zope 2.10 release so that 3rd party software has time to switch. Though I believe that most of the big projects have already switched their interfaces to Zope 3 ones, only keeping the old ones for backward-compat. Philipp ___ 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: Deprecating Zope 2 interfaces?
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: There are a few places in Zope 2 where they are still used for checks (mostly webdav, OFS, ZCTextIndex). In detail these are: 1.) WriteLock: Objects are only lockable if their class has WriteLockInterface in its __implements__ list. OFS.PropertySheets also does this. 2.) PluggableIndex: Indexes for ZCatalog have to be registered in Products.meta_types with PluggableIndexInterface. 3.) IFAwareObjectManager and the 'interfaces' argument of ObjectManager.all_meta_types: The mechanism used for pluggable indexes has a generic implementation in ObjectManager and can be used by any subclass of IFAwareObjectManager. Thanks for tracking those down. According to a search for 'isImplementedBy' (the old interface API method), there's also: 4) OFS.DTMLMethod and ZPublisher.HTTPResponse check for IStreamIterator 5) Products.Trancience checks for TransientItemContainer (no leading I) We should put #BBB comments to all of those locations so we won't forget. Well. All those locations import z2 interfaces so it should be quite easy to find them as soon as the z2 interfaces are removed. For the deprecation period, these checks will have to be done against both the Zope 2 and the Zope 3 interface. In Zope 2.9 these mechanisms already work alternatively with z3 interfaces. Not all of them but most of them. I just meant those 3 mechanisms on my list. 4) and 5) are not migrated, but there should not be many third party products that depend on them. I think this is as hard as it gets for the switch-over to Zope 3 interfaces, but perhaps I'm missing something. Don't think so. But there might be other z2 interfaces in use. Sure, which is why we have the deprecation period for 12 months after the Zope 2.10 release so that 3rd party software has time to switch. Sure. I meant in use in Zope 2 itself. But your search for 'isImplementedBy' should have revealed most of them. Though I believe that most of the big projects have already switched their interfaces to Zope 3 ones, only keeping the old ones for backward-compat. Zope 2.8 compatible products still have to use WriteLockInterface and z2 interfaces for IFAwareObjectManager. Cheers, Yuppie ___ 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] Re: The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 19:24, Martin Aspeli wrote: My immediate concern is about resources: Who will have the time or incentive to police the common repository and grant certification? It seems to be a non-trivial process that may end up being quite time-consuming. It may be perceived as too much red tape. Please read section 2.8 carefully. Here is the most relevant part: Both, the requirements and process, are developed in a way that it should be also simple and fast to receive certification level 1 and level 2. The turn-around time of a request for being granted a certification level 1 or level 2 should be about 1 day. The certification of level 3 will usually take some more time, since it requires the certification manager to inspect the code in much more detail. However, the certification time should not exceed a couple of weeks. Overall, it is very important for the process to have as little overhead as possible and make the certification process a quick, easy and fun experience. It may be perceived as too much centralised control, especially around licensing. In the sense that the Zope Foundation is giving out the certifications, yes, it is centralized. But this is necessary, to make the process seem valuable/legitimate. All other certifications are centralized too, such as the TÜV controls the C2 security certification process. In terms of license, the ZSCP makes no assumptions. Even commercial projects can be certified if they show a certification manager their code. All of section 2 does not talk about a required license. A particular license will only be asserted on the Common Repository, like the ZPL is now for svn.zope.org or the GPL for the Plone core. Secondly, and partly because I'm expecting this to come up in my absence: your proposal is eerily simlar to Alan's two-level Plone collective post to plone-dev, about having an approved list of contributors and packages in a fenced-off repository, in addition to the collective. Yes, I am surprised he posted that. He was on the pre-proposal committee and knew for a while this was coming. As you can see in Appendix 3, there were several Plone developers involved in the recent discussion. One obvious parallel here, by the way, is with the svn.plone.org/plone repository. That one is controlled by the Plone Foundation, requires a contributor agreement, and imposes restrictions on license and quality (albeit not as formally as you do). I think this is possibly a more valid comparison than with the Collective. Yeah, probably. As far as I understand the Goldegg protocol, the goal is to develop generic components that could be under a different license. So ideally I would like to have those components live in the Common Repository, but they do not have to. I have mentioned that at various places in the repository. I'm actually +1 on your proposal in spirit (if it can be shown to work, and if there is a broad consensus in the community to support it - in fact, this is important: if there is too much division, the proposal would likely be self-defeating) and -1 on his. Great! I agree with your reservation; but we have to try and from the comments I got from the pre-proposal committee (which represent a wide range of Zope sub-communities) I was encouraged that we would find a general agreement. snip discussion on Plone versus Zope 3 development eltism and a raised bar to entry. I think that balance is different in Plone than it is in Zope 3. Yes, I agree. Thus the proposal clearly states in section 3.2: The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team. Put differently, I think that *some* Plone components ought to move lower down the stack, target re-usability in different systems, and thus be subject to somewhat different rules. Perhaps these components shouldn't have been Plone components in the first place, or perhaps their evolution would start in Plone and move down the stack. But I think it would be damaging for the Plone community, given its current shape and culture, to impose those rules across the types of components that are higher up the stack - arguably those components which should be Plone components still. I would never try to do this. 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 )
[Zope-dev] Re: [Zope] The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 20:09, Andrew Milton wrote: So in order to even get your Open Source package LISTED, you have to sign over the rights of your code to Zope Corp (currently, Zope Foundation later), and then check it into the svn respository. Is this is correct? NO! ABSOLUTELY NOT! The ZSCP is totally disconnected from the Common Repository. Note that the ZSCP does not talk about any repositories or technical implementation. It only talks about the certification goals, requirements and data. So you're proposing that the Zope Foundation will not even mention other Open Source code that isn't actually owned and controlled by the Zope Foundation? Huh? Where did you get this idea from? Did you actually read the proposal? Having a standard Zope package format would be far far more useful to the users at large, along with the associated tools (so developers can create compliant zope packages, and users can install packages actually using Zope). Packaging tools can then enforce certain restrictions automatically and create a manifest. We cannot require something that we do not have. Thus I did not address packaging or strong dependency meta-data in the proposal. I think once we investigated eggs and have some initial implementation, the proposal will be updated in light of this. If you had that, then that would certainly ease adding 'stuff' to the 'certified' repository, getting to LISTED level would be automatic. Becoming listed will be a nearly automated process. Also receiving level 1 and 2 will be quick decisions. This is clearly stated in section 2.8. I have added a questions to the QA section clearly stating that the ZSCP does not require packages in the Common Repository. 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 )
[Zope-dev] Re: The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 23:16, Philipp von Weitershausen wrote: No. The common repository under the wings of ZC/ZF is just *a* repository that implements the ZSCP. There can be others, for example the Plone repository, the collective repository (perhaps), etc. Correct. I had earlier suggested to Stephan that we should keep the common repository separate from ZSCP and there out of this proposal. IMO there should be a separate proposal for the common repository. I guess he didn't agree. I did agree that the two were too intermingled and thus clearly separated them. However, I personally do not have the resources to push two separate proposals on this, since I think the two are so closely related; in fact at the beginning I thought of them as one. If the common repository would not be part of the proposal, I would feel that people would dismiss it as nice to have, but it ain't gonna happen. It is very important to me that we will be able to implement the process quickly and get on our way certifying packages. I think both the ZSCP and the common repository (in the context of the ZF) are a great idea. We should try to have as much stuff as possible in the common repository, but we shouldn't make the process dependent on it. Correct. The latest revision clearly separates the two. To show their independence, I have (a) placed the two subjects into two separate main sections, (b) made sure that none of section 2 (ZSCP) requires anything from section 3 (the repository), and (c) made sure that the process does not depend on Open Source licenses or information that would only be known in public projects. I have spent a lot of time trying to be *very careful* rereading the sections over and over again. If you find that anything in the document contradicts those 3 points above, let me know! I am very interested in fixing those type of bugs! :-) 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 )
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Monday 20 February 2006 23:55, Andrew Milton wrote: Wow, you took the following two quotes out of context. block quote The Common Repository is *not* a replacement for other high-level repositories like Plone's or ECM's. It does not aim at assimilating everything in the wider Zope community. It is merely a place for high-quality packages that are supported by the Zope development team. ^^^ This is from section 2, which defines the ZSCP. Code in the Common Repository *must* also use the license stated in section 3.5 and developers *must* sign the contributor agreement. The ^ agreement is necessary to ensure that contributions originated from the contributing developer. /end quote This is from section 3, which defines *one possible implementation* of the ZSCP. But I see where your confusion stems from and I have added a paragraph to section 3.1 stating that the Common Repository is one implementation of the ZSCP but not the only one: The Common Repository is only *one* implementation of the ZSCP. While the Common Repository implements the ZSCP guidelines and suggested automation tools, the ZSCP process itself does *not* require the Common Repository. The license for the code should also be irrelevant, since it's just a repository right? Just a convenient one stop shop for packages. So each package should be able to have its own license, no need for a common license. For the ZSCP, the license is irrelevant. For the Common repository it is not. Having to sign the agreement serves no purpose unless there's some other IP issue involved other than simply storing the code. The following does *not* concern the ZSCP, but the code and repository: Right, the other issue is upstream movement. Let's say you have a package that has many contributors, like zope.interface, and the Python developers would like to put the interface package into the Python standard library. Since zope.interface is ZPL and Python has its license, you need to change that. If you do not have a contributor agreement that assigns half of the rights to an organization, then you have to ask *all* developers whether the license change is okay. If you cannot find a developer anymore you can never change that license. 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 )
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 03:57, Philipp von Weitershausen wrote: Putting stuff into svn.zope.org *does* have advantages: * it's easy to feed packages upstream to Zope for a later inclusion into a Zope distribution. * putting a project/package under the wings of the ZF ensures long-term IP protection * code in svn.zope.org will be under the common control of the Zope developers which makes long-term maintenance easier to ensure. * the common license (ZPL) and the common ownership of the ZF do away with some legal headaches... Very good summary. Better than mine. :-) 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 )
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
snip IP discussion Okay, this discussion is off-topic. I will not respond to it, unless I read about something that relates directly to the proposal. 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 )
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:13, Andrew Milton wrote: Why should Mark Shuttleworth who has plenty of means, hand over IP for (parts of) SchoolTool? I'm sure he has more than enough ways to protect his IP. Or are you saying that it makes sense for ZF/ZC to protect him? The reason the SchoolTool project would be interested in putting a couple packages in the common repository would be so they are moved into the Zope 3 core pr are part of the distribution. It would mean that the SchoolTool developers have to maintain less code. However, we do not need to put all of SchoolTool into the repository just to get certified. We can ask for certification with the SchoolTool code living in another repository. In fact, I think SchoolTool might be one of the first outside projects to gain certifications, since it is the only large project that I know of that fulfills the level 2 requirements (I think it could even get level 3). 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 )
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:30, Philipp von Weitershausen wrote: Anyways, you're welcome to contribute code to the z3base if you'd prefer a public repository that doesn't require IP handover/sharing. Who knows, perhaps we'll even manage to implement the ZSCP for some packages there :). That would be very cool! :-) 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 )
[Zope-dev] Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 07:15, Andrew Milton wrote: The proposal currently requires 3rd party code to be handed over to Zope Foundation[1] AND checked into the ZF svn repository in order to be 'certified'. You indicated this was indeed the case. That's not true. Phillip and I both negated this assertion. Where did you read this? The quotes you had earlier were totally out of context. Nothing in Section 2 requires anything of section 3. 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 )
[Zope-dev] Re: [Plone-developers] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 08:47, whit wrote: what hopefully zscp would do is allow a code commons at one end (ala collective, easy entry, friendly to experimentation) and a fully certified set of components at the other. In between, there would be well defined process for how software moves from the primordial ooze to canon. Well said. 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 )
[Zope-dev] Re: [Zope3-dev] Re: [Zope3-Users] Re: The Zope Software Certification Program and Common Repository Proposal
On Tuesday 21 February 2006 05:38, Stefane Fermigier wrote: However, I believe like you Philipp, that both initiatives should be decoupled. The two things are decoupled as section 2 does not require section 3. I decided to leave it in the same document for several reasons: (1) Bandwidth. Discussing two proposals of this size separately requires a lot of time. (2) I fear that the ZSCP would be talked to death and stay dead. My experience in the Open Source world has shown that if something does not have practicality, it dies unless someone is getting paid. I am certainly not getting paid for this. By biggest interest here is to bring the sub-communities together and define communication means on the code level. (3) If the ZSCP is discussed in too much abstraction, it will distance itself from what we can and want to do. While writing I have always used the Common Repository as reality check. (4) If the two were talked about separately, I think we would go back and forth on what information and process is needed. Right now, with the Common Repository in mind, I know exactly that the steps of the ZSCP will work. Overall, once we have a general agreement, section 2 will be lifted out of the proposal anyways to represent the first set of rules for the ZSCP. This document is proposal not just the rules. BTW, I am sorry for the confusion. I should have documented this better. I know I had in the earlier version, but it must have got lost. I have now added a section right at the beginning of section to communicate the separation better. 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 )
[Zope-dev] Re: [Zope3-dev] Re: [Zope3-Users] Re: The Zope Software Certification Program and Common Repository Proposal
Stephan Richter wrote: (2) I fear that the ZSCP would be talked to death and stay dead. My experience in the Open Source world has shown that if something does not have practicality, it dies unless someone is getting paid. I am certainly not getting paid for this. By biggest interest here is to bring the sub-communities together and define communication means on the code level. I don't think it will stay dead, because it is really exciting :) S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ 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 branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 3191 Blamelist: frerich,hdima,mkerrin,philikon,srichter,whitmo,yuppie 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 )
