Re: [Caml-list] OSR - "Batteries included" - Standardizing syntax extensions and extra libraries

["Jim Miller" <gordon.j.miller@gmail.com>]

This is an excellent exposition of what I agree are the real issues in
this effort.  Technical issues are the easy ones to solve, its the
non-technical that get hard.  I've looked at the old CDK archives and
didn't see a summarized list of the reasons why it was being shut down
but I'd be really interested in hearing a brief summary, many of which
I'm sure are reflected in Alain's comments below.

My personal opinion (FWIW) is that I'd like a CDK type thing, or at
least have the ability to put an OCAML-OSR "release" onto a CD.  I
work in a LOT of environments where we don't have access to the
Internet and I end up having to copy stuff back and forth on CD.  (USB
pen drives are beginning to be restricted so yes, it tends to be CD).
Having a fully contained distribution where I KNOW that I have
everything, or at least know everything I have, would save a huge
amount of the frustration I've had over the years.

>  - what is the intended audience? The will influence both the selection
>  process and the motivation of people putting efforts into the distribution.

I believe that the audience should be the non-sysadmin developer.
While existing package management schemes are great the system should
not require root access to install.

>
>  - what is the policy w.r.t. to upgrades of libraries? It is very common
>  that a new version of a library break existing code, so simply upgrading
>  as soon as possible might not be the best choice. Should several
>  versions of OCaml-OSR be maintained in parallel?
>
>  - what should be done when a library doesn't work out-of-the box for a
>  new version of OCaml? Should it be removed (temporarily) so as to allow
>  an early distribution of OCaml-OSR with the new OCaml?
>
>  - who's in charge of maintaining a web site, upgrading libraries,
>  testing for several architecture, preparing releases, etc?  This is a
>  lot of work, so a collaborative approach might be needed, but
>  responsibilities need to be defined.
>

I'd support three variations.  Stable, Unstable, and Experimental.
Having a lifecycle that introduces a new release at the Experimental
phase and having it move through Unstable to Stable would allow for
sufficient testing.  Libraries that are being considered for a release
could be included in the Experimental phase with the requirement that
once it moves to Unstable, that the API must remain the same.  A new
major version of the library, one that breaks the API, would have to
be introduced in the next Experimental release.

There are then two ways to assign people to this.  A different
individual, or group of individuals, can take ownership of a release
when it is first created in the Experimental state and continue owning
it until it moves into the Stable state.  The second way is to have a
team that handles a particular stage and hands a release to another
team.  The level of commitment at the Experimental state is much
higher than the Unstable, which is much higher than the Stable.  By
the Stable release the managers would hopefully only be rolling in
minor bugs and rebundling, if necessary.

>  - will there be binary distributions? (Relying on Debian/Fedora/...
>  OCaml developpers does not solve the question for Windows.

I think that the primary OCAML-OSR release should be in source form
only, Godi style.  If other people want to release binary packages
then they can sign up to do that.  It should be a different group of
people from the OCAML-OSR maintainers described above.

>
>  - will the addition/upgrade of a single library force to reinstall all
>  of OCaml-OSR, or will the distribution be made modular?

Distribution should be modular but there is a case that can be made
for a monolithic install.

>
>  - will there be a common place to find the documentation for all the
>  selected packages?

I think that the documentation should be included as part of the
distribution itself.  I think that this is one thing that the JDK did
right.  Having the documentation for the entire library in one place
is very nice and something I find frustrating about OCaml.  I've gone
so far as to hand create my own JDK-ish page with all of the libraries
I use ... I'd like to see something more standard as part of this.

>
>  - will libraries that depend on C code and/or external components be
>  accepted?

I think that the distribution needs to be self contained.  Any C
libraries that are required by it must be installed during
installation if they don't already exist on the system.  We run into
this issue with software distribution all the time for our C++ based
systems.  We depend on many libraries but depending on the system they
may or may not be present.  This is a royal pain.

I think that anything that either can't or shouldn't be distributed
should be packaged as an extension to the OCaml-OSR release and not
part of the core.