Michael J Forster wrote:

>On Wed, Dec 14, 2005 at 11:51:29PM -0600, Cody Koeninger wrote:
>  
>
>>On 12/14/05, Michael J Forster <[EMAIL PROTECTED]> wrote:
>>    
>>
>>> I'm talking about one site (mirrors
>>>aside) with consistent layout and navigation, one agreed upon set of
>>>standards for documentation and testing, and one ASDF-INSTALL
>>>compatible repository.
>>>      
>>>
>>Can I get a HELL YEAH?
>>Documentation-wise, the only contenders I'm aware of are Albert and
>>CLDOC; I can try to put together a comparison.
>>Testing-wise, there are scads of libraries; anyone interested in
>>furthering the comparisons linked from
>>http://www.cliki.net/Test%20Framework ?
>>Or did you actually mean 'standards', rather than 'standard implementations'?
>>    
>>
>
>I meant 'standards' as in a policy, a set of conventions, principles,
>prescriptions, and proscriptions.  Like the GNU coding standards,
>Debian policies, or FreeBSD port maintainer guide, such standards
>could recommend or require specific tools and implementations.
>However, at this point, my inclination is to think about and discuss
>the value and scope of the standards rather than any specific rules.
>
>Please understand, bureaucracy is not my goal.  The consistency,
>clarity, and completeness of Edi Weitz's library pages [1], as an
>example, are.
>
>Of course, we don't have to wait to have a policy in hand before
>investing some time and effort in reviewing the available tools.
>  
>
Let me say that having the modules available in a single location would
be a very big plus.   Having them be available in formally numbered 
releases,
perhaps as rpms or the equivalent, would also be nice, as would access
to a public cvs/subversion/etc. server.  It should be possible to deliver
snapshots of the packages as a collection that can be used without net
access.  This latter is essential if the packages are to be used in any
real commercial software; no company will make their build process
depend on the random availability or state of packages off on some server
they don't control or have a contract with the operator of.  Good CM
practices (this is stuff needed to get to CMM level 2, folks) requires that
the build process be deterministic and completely defined, so you can
reproduce your deliverables exactly.

    Paul
 
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners

Reply via email to