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

[Maxence G. <max...@in...>]

Hi,
=20
> First of all, I think we should try not to talk about COAN or something l=
ike
> that right now. Why ? Because the discussion has still to go on on the ma=
in
> OCaml mailling list, and such idea has already been raised a few time, but
> no global agreement was found amoung the community. And also, because I
> would like to wait what for example Maxence Gesdon, the OCaml Hump author,
> is thinking about it.

Well, the humps are basically just lists of=20
- applications, which can be seen as code examples and proofs that OCaml is=
 a
real-world language,
- libraries to reuse
- and docs to learn and make better use of the language.

There is no concept of installation nor dependencies in these lists. I woul=
d say
it's degree 0 of a code repository.

From the experience of Fabrice Le Fessant and Alan Schmitt (and others) in =
the
CDK, putting together libraries is a nightmare : different makefiles styles,
compilation procedures, ...

So before thinking about COAN, the important point is to define *standards*=
 for
OCaml documentation, compilation and installation :
- documentation : ocamldoc can help
- compilation : various os must be taken into account
(Linux/Unix/Window$/MacOS), byte and native code generation,
- installation : I agree that ocamlfind would help on this. A fetch
functionality would be needed too, =E0 la debian apt-get.

Once this is defined, then we can think about COAN, but not before. So I ag=
ree
with Nicolas.

> Few rules I think we should follow :
>=20
> - the ExtLib ( or any other name if you don't like this one :) has to rem=
ain
> 100% OCaml code ( no C part ! )
> - 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 ]
>     * it provide a simple convenience which can be heavily used in any ki=
nd
> of application [ simple and heavily are the keyword ]
>     * (adding this one) it provide standardized access to a commonly used
> data structure [ standardized is the keyword ]
> - 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.
=20
> How to process :
>=20
> - 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
>=20
> 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 =E0 la ocamldoc, an agreement could be reached quic=
kly.

--=20
Maxence Guesdon
=20