[SciPy-dev] Re: Formal Review Process

[Robert Kern]

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
here.

[snip]

>> 3. The Boost project had a similar problem, found a solution that worked
>> for
>>    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
> instance.


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.  :-)

>> Organization
>> ------------
>> 
>> 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.

> <snip>
> 
>> 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.

[snip]

> 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)

Nifty! +1.

However, we still may want to deal with the issue of modules needing to
modify, say, scipy_core/scipy_distutils/system_info.py .

> Pearu

-- 
Robert Kern
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