Re: [Ocaml-lib-devel] Goals & Process

[fva <fv...@ts...>]

By way of informal vote on the proposal by other people...

Maxence Guesdon wrote:

>So before thinking about COAN, the important point is to define *standards* for
>OCaml documentation, compilation and installation :
>- documentation : ocamldoc can help
>
Agreed

>- compilation : various os must be taken into account
>(Linux/Unix/Window$/MacOS), byte and native code generation,
>
Agreed, if not taken to mean "every contributor will make sure that 
his/her code runs on all platforms", only on the spirit of the project.

>- installation : I agree that ocamlfind would help on this.
>
Agreed.

>A fetch
>functionality would be needed too, à la debian apt-get.
>
Agreed.

>Once this is defined, then we can think about COAN, but not before. So I agree
>with Nicolas.
>
Agreed.

>>Few rules I think we should follow :
>>
>>- the ExtLib ( or any other name if you don't like this one :) has to remain
>>100% OCaml code ( no C part ! )
>>
???? Don't have a strong opinion. Wouldn't object to good wrappers it 
OCaml code was not available. Better see it well documented and filtered 
through signatures than not see it at all.

>>- any ExtLib part should match at least of of theses properties :
>>    ( from JMSkaller speaking about the C++Boost Library )
>>    * it provide important functionnality which is hard (or take time) for
>>the client to code up correctly [ important is the keyword ]
>>
Agreed

>>    * it provide a simple convenience which can be heavily used in any kind
>>of application [ simple and heavily are the keyword ]
>>
Agreed

>>    * (adding this one) it provide standardized access to a commonly used
>>data structure [ standardized is the keyword ]
>>
Agreed (Hard, this one!)

>>- since right now the inclusion of bytecode in a binary is file-based, the
>>ExtLib has to be split in several files to keep the users binaries small
>>
Agreed. (A writing a single structure/functor in each file?).

>
>Agreed.
>

>>How to process :
>>
>>- each developper develops its own branch of the ExtLib
>>- once a developper has a branch ready, he have to ask for peer review /
>>comments from the ExtLib developper community
>>- if the community reach an agreement on branch committing, the branch is
>>added to the ExtLib
>>- if the community don't reach an agreement, it's in the end ExtLib
>>administrators ( no more than 3 or 4 people ) who are deciding to add it or
>>not
>>- if the community mostly disagree, the branch is not committed, and
>>administrators don't have to settle
>>- once a branch is committed, its maintainer is no longer the original
>>developper, but the whole ExtLib community
>>- ExtLib bug fixes are addressed directly to the administrators which can
>>either patch the ExtLib or classify it as "not a bug"
>>- ExtLib existing branch improvement/addons use the same process as
>>committing
>>
Agreed to everything (but would think twice about opting for 
administrator of the library in this conditions).

>>All theses are proposals, if the current people here ( who's in there ? :)
>>agree then it would be nice to put theses rules somewhere in the ExtLib
>>FAQ/Rules.
>>    
>>
>
>Hum, this does not prevent various developpers to code the same functions, and
>the admins will still have to choose among hundreds. If they aren't afraid, we
>can do that, but I still think a discussion about what's needed would save time.
>I agree this kind of discussion can be messy, but by giving the types of the
>functions and a comment à la ocamldoc, an agreement could be reached quickly.
>
Let contributions be made on a signature or structure basis... Let 
people meet and present whole signatures and structures instead of just 
functions. Or at least encourage them to... (I am aware that some 
functions just do not belong in a (single?) signature).

Regards,

        Fran Valverde

>
>  
>