[SciPy-dev] Re: Formal Review Process
kern at caltech.edu
Sat Sep 20 13:56:45 CDT 2003
Pearu Peterson wrote:
> On Sat, 20 Sep 2003, Robert Kern wrote:
>> A Proposal for a SciPy Module Submission Review Process
>> :Author: Robert Kern (parts by the Boost_ group and others__)
>> :Version: 0.0
>> :Date: 2003-09-20
>> The following proposal is inspired by (and indeed partly outright lifted
>> from) the `Boost Formal Review Process`_ and `Submission Process`_. It is
>> written using ReStructuredText_.
> Did you check out PEP-2? I think there are several things that the Boost
> document does not cover: maintaining a module, for one instance.
Not until now, no. But you're right, it has good ideas to steal. The
integrator/maintainer concepts are quite useful. And yes, maintenance
needs to be addressed though I think it should be fully covered in a
separate SciPy Development Guide or something and briefly summarized
>> 3. The Boost project had a similar problem, found a solution that worked
>> them, and wrote it up all pretty, so why not steal it? [XXX - or
>> something to this effect]
> Hmm, I guess there are several projects with the same problem. Python, for
You're right, and I will look at the PEPs you suggest. Boost was just
the most salient project in my head when I started thinking about this.
> I would leave this item out and mention Boost, say, in
> acknowledgements (somehow so many references to Boost were annoying to me
> while reading this document;-).
Sorry. When I commit larceny on so comprehensive a scale, I feel guilty
and try to give advance warning. :-)
>> Mailing List
>> Discussion of libraries under formal review shall take place on
>> scipy-dev at scipy.org . Actual reviews of a candidate module (see section
>> `Reviews`_) during its formal review period should begin their Subject
>> header with
>> [REVIEW - <name of module>] for the convenience of the Review Manager.
>> Reviewers who do not wish to subscribe to scipy-dev at scipy.org may use the
>> GMane_ WWW_ and Usenet_ interfaces to the mailing list. The WWW_
>> interface does not allow posting. [XXX - to be honest, I don't know if
>> the Usenet_ one allows posting for this list, either.]
> AFAIK, only members can post to scipy-dev mailing list.
I am posting this via GMane, so it must work.
>> The Process for a Module Submitter
>> Determine Interest
>> Post a message to scipy-dev at scipy.org to see if there is interest in your
>> module. Describe what your module does and perhaps include a small
>> snippet of code that shows how one uses it.
>> Preliminary Submission
>> Put your (possibly unfinished) module on a website and post its location
>> to scipy-dev at scipy.org . Contact the maintainers of www.scipy.org for a
>> Zope account if you need web space for your module.
>> Submissions should follow the Code Submission Guidelines [XXX - this
>> should point to something useful. For now, look at the `Code Formatting
>> Guidelines`_ and the `Testing Guidelines`_.]
> See also PEP-7 and PEP-8.
> Along the lines in PEP-2, submission should include a rather complete
> documentation in order to get a better picture of the module when it will
> be finished. Such a document may contain also ideas/suggestions on future
> extensions of the module by proposing, say, function signatures. Such
> functions are allowed to be implemented even after the module is accepted
> to Scipy package.
> Since Scipy should provide a solid base for scientific work, all modules
> should have a mathematical background documented, most importantly,
> the formal definitions of used concepts. This would allow verifying the
> correctness of the results as well as avoids misusing the provided tools
> by the end users who might know/use slightly different definitions for
> some mathematical concepts.
Agreed. As alluded to above, I think all of these requirements should be
wrapped up in a separate SciPy Development Guide since the information is
useful to maintainers as well as potential contributors and because it is
likely to be longer than this document is already.
> Such a setup should be as simple to use as possible: adding a new module
> would require two steps:
> 1) unpack module to the sandbox directory
> 2) create a pre__init__.py file to the module directory (unless
> submitter already had done that)
However, we still may want to deal with the issue of modules needing to
modify, say, scipy_core/scipy_distutils/system_info.py .
kern at ugcs.caltech.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Scipy-dev