February 2006 - Zope-Dev

Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
by Philipp von Weitershausen 21 Feb '06

21 Feb '06

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

2 1

Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
by Stephan Richter 21 Feb '06

21 Feb '06

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

1 0

Re: [Zope] The Zope Software Certification Program and Common Repository Proposal
by Stephan Richter 21 Feb '06

21 Feb '06

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 Q&A 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

1 0

Re: The Zope Software Certification Program and Common Repository Proposal
by Martin Aspeli 21 Feb '06

21 Feb '06

On Mon, 20 Feb 2006 21:28:09 -0000, Stephan Richter <stephan.richter(a)tufts.edu> wrote: > 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! Hi Stephan, I have only skimmed the document, since it's 1am and I'm going to the mountains tomorrow. I expect a triple-digit post count in this thread when I return. :) I think the proposal is very well put-together. I think it admirably tries to make the Zope 3 community more inclusive of more peripheral developers who simply use the framework, and I think this will benefit Zope immensely if done right. 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. It may be perceived as too much centralised control, especially around licensing. At times it may also be open to debate, and a means of resolving disputes would seem necessary. There are certainly a lot of tick-boxes in your table! :-) 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. 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. 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. The reason is that the Plone world is quite different from the Zope 3 world (although there are hard-core Plone developers who sit in both). The Plone community is much larger but naturally also more dispersed. The software is much more narrowly defined (depending on your point of view I suppose, but I mean - it's a CMS, Zope 3 is a framework) and the components developed for it are much closer to the user. Plone thrives on the size and vibrancy of its community. A very large part of its success comes from third party products that people find and marry with Plone to solve their problems. Without the low bar to contributing such components, without an open and very democratic Collective, and without "meta-data" on http://plone.org/products, I don't think this would be possible, certainly not as successful. The uptake of third party product users and contributors, and I think maybe also the quality, has improved quite significantly since we introduced the Products section on plone.org. A framework like Zope 3, and framework-level third party components, thrives more on control and consistency in vision and implementation. (In part, you're solving that with better guidelines around how to write code, guidelines that Zope 3 adopters also benefit from.) I think that the lower down the stack you go, the higher the degree of centralised quality-control needs to be. This, however, is at the expense of perceived eltism and a raised bar to entry. I think that balance is different in Plone than it is in Zope 3. 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'd also note that we solve (or try/continue to solve) some of the visibility and evaluation problems on http://plone.org/products (which is of course open source, albeit GPL, and you can re-use any of this you see fit). Some of those same things, you solve with more technical means - automated testing, common file layouts, XML metadata files. Again, I think these approaches work better at the small-component-high-reusability/framework level than they do with the types of user-facing components that typically land in the Collective. Although you proposal is not technical in design, it's technical in implementation (so to speak). Perhaps it would be fair to say that the Collective is almost entirely social in its implementation. I think it's worked very well. For Plone. Martin P.S. If you have specifics you'd like me to respond to, please cc me, since I'm offline until Sunday night (and it was just getting interesting, damn). -- (muted)

2 1

Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal
by Philipp von Weitershausen 21 Feb '06

21 Feb '06

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

1 0

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 21 Feb '06

21 Feb '06

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

1 0

Pluggins vs Application Definition
by Jim Fulton 21 Feb '06

21 Feb '06

Some recent discussions on the distutils-sig mailing list have helped me to understand some issues related to the ways we extend the Zope application server. Traditionally, in Zope 2, you extended Zope by "dropping" product packages into a special "Products" package. This was very convenient in many ways, but doesn't always provide enough control or visibiity to what's going on. In Zope 3, we went with a more explicit installation mechanism, in which people had to explicitly cause a package's ZCML files to be loaded for it to be used. We added a mechanism to make this easier, by simply dropping a file into a special directory, package-includes, so an installer wouldn't have to fool with pointy brackets. I've noticed that at Zope Corporation, for our customer projects, we tend not to use package-includes. We prefer to explicitly include packages we use directly oin our application ZCML files. (As applications, may be composed of several layers, we may include things at multiple levels.) In thinking about this, I realized that there are two different users here with different concerns: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding "pluggins". If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. In summary, I think we need *both* approaches, as they serve different needs. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

10 23

The Zope Software Certification Program and Common Repository Proposal
by Stephan Richter 20 Feb '06

20 Feb '06

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! In the pre-publication phase of the proposal, I have worked with a small committee to receive initial feedback. For the purpose of this proposal, I will not be representing a particular Zope sub-community, but instead act as a mediator among the parties of interest. I will try my best to answer all concerns and comments in a neutral manner. I would like to thank all pre-proposal committee members for their time and valuable input. Thanks for your time! Regards, Stephan P.S.: Sorry for the cross post! -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

1 0

already have current data for oid
by Peter Zechmeister 20 Feb '06

20 Feb '06

Hi, I am experimenting with ZEO. Sometimes I get this Error: ValueError: already have current data for oid (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: already have current data for oid) It starts with one URL in one ZEO-Client and after some time the whole ZEO-System gets "infected". A restart of the ZEO components is needed to make everything work properly again then. In addition to that sometimes it seems that not every change in ZODB gets anticipated by every ZEO-Client. Some Clients insist on delivering "Ressource not found" while some others find these new objects. The whole thing is complete unpredictable and seems not to follow any rules. Our system: Apache - Pound - 5x ZEO-Client - ZEO-Server Zope 2.8.5 The Server has 2 CPUs. I am experimenting on this machine alone in the moment. So the load should be on a minimum at all. What could be the reason for this here? BR PeterZ

1 0

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 19 Feb '06

19 Feb '06

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: 3145 Blamelist: andreasjung,jens,shh BUILD FAILED: failed test sincerely, -The Buildbot

1 0