The Zope Software Certification Program and Common Repository Proposal
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
+-------[ 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? 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? I think there needs to be some other certification process that doesn't require the code to be owned by someone other than the original authors. 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. If you had that, then that would certainly ease adding 'stuff' to the 'certified' repository, getting to LISTED level would be automatic. You might want to change the word Certification to Compliance. So, a package Complies with the Common Repository Standards, rather than is Certified By Zope Foundation. Certification implies a level of dilligence I don't think is actually being applied by this proposal. -- Andrew Milton akm@theinternet.com.au
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. Philipp
+-------[ 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. -- Andrew Milton akm@theinternet.com.au
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
+-------[ 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 akm@theinternet.com.au
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
+-------[ 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 akm@theinternet.com.au
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
+-------[ 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 akm@theinternet.com.au
I seem to have confused myself with the replies. Check into Repository not required for Certification. -- Andrew Milton akm@theinternet.com.au
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
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
<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
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
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
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
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!
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
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!
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
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
On Mon, Feb 20, 2006 at 04:31:03PM -0500, Stephan Richter wrote: Hi Stephan, 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. Would there be room for a voting or feedback step in the process where people that have tried the module could enter a rating?
1.2. Goals [...] * Quality Packages
There is a natural desire for any developer to know what they are getting into when they are using a certain package, a baseline of quality that can be expected. While the Zope 3 community has some ideas of what that baseline is for the core, it is not well defined and applied uniformly. This proposal defines clear quality guidelines.
[...]
2.4. Quality Metrics ~~~~~~~~~~~~~~~~~~~~
The certification is meaningless without the precise definition of tasks that have to be accomplished for each certification level. This section provides a list of concrete items that have to be fulfilled for each certification level.
Legend:
- x: A metric is required for the certification level. - A: The metric check can be conducted automatically. - Q: The metric check can be conducted quickly by human inspection. - D: The metric check would be difficult to conduct by human inspection.
+------------------------------------------+-------+------+------+------+------+ | Metric | Check | List | Le 1 | Le 2 | Le 3 | +==========================================+=======+======+======+======+======+ | Package Meta-Information (see sec. 2.5) | A | x | x | x | x | +------------------------------------------+-------+------+------+------+------+ | Test Coverage | A | 0% | >90% | >95% | >95% | +------------------------------------------+-------+------+------+------+------+ | Tests verified by Automated Test Runner | A | x | x | x | x | +------------------------------------------+-------+------+------+------+------+ | Doctest-based Testing | A,Q | | x | x | x | | (or list reason for not using doctests) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Tests pass on all supported platforms | A,Q | | x | x | x | +------------------------------------------+-------+------+------+------+------+ | Minimal Documentation | A,Q | x | x | x | x | | (``README.txt`` file) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Complete Documentation | Q | | x | x | x | | (Text files cover all of API) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Extensive Documentation | D | | | | x | | (lots of samples, API docs, tutorial) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Documentation available online [1] | Q | | | x | x | +------------------------------------------+-------+------+------+------+------+ | Documentation available in Zope's apidoc | Q | | | x | x | +------------------------------------------+-------+------+------+------+------+ | Common package structure | A,Q | x | x | x | x | +------------------------------------------+-------+------+------+------+------+ | Follows Zope Coding Style Guide | A,D | | x | x | x | +------------------------------------------+-------+------+------+------+------+ | Conform to user interface guidelines | D | | | x | x | | (if applicable to package) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Complete dependency list | A | | x | x | x | +------------------------------------------+-------+------+------+------+------+ | Standard installation method | A,Q | | | x | x | +------------------------------------------+-------+------+------+------+------+ | Release(s) with version number | A,Q | | | x | x | +------------------------------------------+-------+------+------+------+------+ | Up-to-date homepage | D | | | | x | +------------------------------------------+-------+------+------+------+------+ | Active support mailing list | D | | | | x | +------------------------------------------+-------+------+------+------+------+ | Released for at least 3 Zope releases | D | | | | x | +------------------------------------------+-------+------+------+------+------+ | Releases state required Zope version | A,Q | | | | x | +------------------------------------------+-------+------+------+------+------+ | Multiple (3) Active Maintainers | | | | x | x | +------------------------------------------+-------+------+------+------+------+ | Data migration claimed | Q | | x | x | x | | (if applicable) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Data migration auto-tested | A | | | x | x | | (if applicable) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Data migration verified | D | | | | x | | (if applicable) | | | | | | +------------------------------------------+-------+------+------+------+------+ | Data migration well-tested | D | | | | | | (if applicable) | | | | | [2] | +------------------------------------------+-------+------+------+------+------+
-- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________
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
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
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
Hi Stephan after having quickly read your Proposal I think there are some nice ideas in it. A central Zope(3) Software Repository with certified components would make life a lot simpler for many of us. And this could also be used for marketing purposes as well. However I doubt that it is possible to to do all that Certification Stuff - afaik the core developers are all very busy people, and judgement of code quality doesn't seem that simple to me. But thats just my 2c Kind Regards Maik
On Wednesday 22 February 2006 10:37, Maik Ihde wrote:
However I doubt that it is possible to to do all that Certification Stuff - afaik the core developers are all very busy people, and judgement of code quality doesn't seem that simple to me.
I should know. :-) The process is designed in a way that up to level 2 most of the tasks can be automated. Thus it should only require some human interaction. We have to try, otherwise we will not know. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
participants (7)
-
Andrew Milton -
Chris McDonough -
Maik Ihde -
Philipp von Weitershausen -
Reinoud van Leeuwen -
Stefane Fermigier -
Stephan Richter