On 2/21/06, Stephan Richter <[EMAIL PROTECTED]> 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
More importantly here, doctests will give people a good impression on
what you can do. So I would like to change the doctest requirement
(that sais that tests should be in doctest format unless that is not
possible) to these documentation requirements:
1. Having at least one reasonably complete usage example.
2. All code examples in the documentation should be in doctest format,
and included as a part of the standard test-run.
(Maybe you had these in there and I forgot about them, in that case
all is fine. :) )
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
Zope3-dev mailing list