[Zope3-dev] The Zope Software Certification Program and Common Repository Proposal

[Stephan Richter]

On Tuesday 21 February 2006 06:09, Lennart Regebro wrote:
> First, about the IP: The idea that we can use the same certification
> process for different repositories and different code owners is
> interesting. In that case, there could be a common
> listing/certification site, covering several repositories that all are
> a part of the certification process. I like that better than saying
> that the code has to be owned by ZF to ber certified, because that
> more or less kills the idea of certification in the first place... :)

Right. This is the goal. While I have not stated this publically yet, I am 
also committed to develop this Web site. In fact, I have already started by 
writing code to process the proposed data both ways.

> Onto other things:
> > tests (in doctest format)
>
> This seems like a very random requirement for me. I'd like to see
> tests that can be run with the standard test-runner, otherwise I don't
> see a reason to restrict it. I find doctest greating for testing docs,
> and testing longer use cases. Otherwise I don't like it at all, and
> see absolutely no reason to force people to only use doctests.

Why is it random? It is taken straight from the conventions now used in Zope 3 
for all new development. The rationale behind it is that you are forced to 
document and reason all the cases the software handles. This, in turn, makes 
you think much harder about your features and provides other developers to 
understand your code more easily.

If several other people agree with you (and not too many disagree), I will 
change the proposal. But I think it would lower the documentation quality a 
lot.

> > Packages of this level are considered fit for the Zope 3 core with the
> > reservation of the core developers to provide or require small
> > improvements.
>
> I'm not sure I understand what you say here. You say that level one
> packages are almost good enough to be zope 3 core, and that the other
> levels are good enough to be Zope3 core, even though they are not?

All I am saying is that level 1 (and also above, of course) is good enough for 
the Zope 3 core. The second clause is saying: If we accept the package for 
the core, we will reserve the right to make small improvements. For example, 
level 1 does not require the documentation to be available via apidoc, but 
core packages must provide their docs in apidoc; thus we would have to add 
this when adding the package to the core.

I simplified the sentence structure a bit.

> > [1] For small packages it will suffice, if the documentation is available
> >       via a Web site of the repository. For projects having a homepage,
> > the documentation *must* be available there.
>
> When you say "Web site of the repository" do you mean svn access via
> http?

Yes.

> Because there could be more, we could give each project a small 
> auto-generated website which contains documentation and releases, in
> the way of codespeak. This would force every project to keep the
> documentation in the same format, suitable for automatic generation
> into HTML and other formats, which I guess is something we would like
> anyway. In that case, documentation could be on this "project-page"
> and if you have any other homepage for the project, you could just
> link there.

Certified packages must follow the Zope 3 coding style guide, which requires 
the package documentation to be in ReST. So HTML generation is a given thing; 
in fact apidoc book module does just that.

The idea is not to make the barrier too nigh for small packages without 
homepages. On the other hand, the ZSCP site should *not* become a software 
development site. It will only provide pointers to other resources. It is 
very important to keep the focus of the proposal as narrow as possible in 
order to make it feasible to implement. This will not be the last revision of 
the process; if we see the need to provide even more information, we can add 
this later.

> > Achieving the first status of being a listed package is
> > an automated process.
>
> I'm not 100% clear on the "listed" status. A listed package is still
> in the repository, is that right? So anybody with repository access
> can create the package and create the meta data and then list it, is
> that the idea?

Right, this is the general idea. I am not sure whether it will be fully 
automated in the first iteration, but this is certainly the goal eventually. 
The goal of a listed package is to say: Look, here I am, and I am trying very 
hard to fulfill the quality guidelines and become certified.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training