Re: [Caml-list] OCaml maintenance status / community fork (again)

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Dec 12, 2011, at 11:21 , Xavier Leroy wrote:

> - It complicates the lives of OCaml users, packagers, and 3rd-party
>  library developers: what version should they use?  what will be the
>  basis for the packagers's distribution-specific patches?  what
>  happens if a library is compatible with one version but not the
>  other?  what if the community effort runs out of steam in a few years?

If we can adopt the eglibc model, then the community thing will be the version shipped by distributions, i.e. the community thing is the OCaml for distributions/packagers, not an alternative to the official version. That way we do no longer need to maintain specific patches / versions for Debian, Red Hat, MacPorts, etc. This ensures that versions are compatible across different distributions (because they do no longer need to maintain their own set of patches).

I think of the community thing as:

(a) A single place for patches, while waiting for the next official OCaml release.
(b) A common ground for experimenting with new features. As you already noted, feedback and adoption for experimental stuff hidden within the SVN repository wasn't all that great, so maybe we can change it this way (esp. since it would be coordinated with the distributions/packagers to some degree).

> - It means additional efforts with some duplication.  The
>  synchronization between the "community" and the "reference" code
>  bases will take work.  From the core team's standpoint, that's about
>  as much work as dealing with individual suggestions and
>  contributions.  At the same time, the community team will spend
>  non-negligible time organizing and administering itself, at least
>  initially.

The community team (namely the packagers in this case) already spend this time, as already noted by others (i.e. Stephane). And even if that's the same effort for the core team (I doubt that, since if nothing else, you'll at least have a single tested patch set to review, instead of a bunch of independent, incompatible, and probably untested patches), then there's at least the win for the community.

I shouldn't have used the term "fork" initially, this is misleading. Don't get me wrong. Don't think of my proposal as a "OpenBSD vs. NetBSD" thing with a whole new project.

>> Why not accept a model similar to i.e. the NetBSD project, with a
>> lot of committers (experts in their own areas) and 2-3 people to
>> keep an eye on the overall direction?
> 
> Except for the "lot of committers" part, this is pretty much how the
> core Caml team has been working, and there is definitely room for more
> contributors.  As I mentioned earlier, there are a number of areas
> where we're lacking manpower, e.g. Windows-related stuff and tools
> such as the debugger or Camlp4, but many other areas of the system
> would benefit from more contributors too.  Smaller contributions
> are most welcome as well, such as commenting on the PRs, testing
> changes, new features and release candidates, PR triaging, helping to
> identify the top little things to be resolved by the next release,
> etc.
> 
> That's a much more low-key approach, but one that is more likely to
> succeed.  Volunteers are welcome to contact us as caml@inria.fr.

I can help with the low-level compiler and runtime stuff, others have already expressed their intention to help with Camlp4, etc. You'll receive an email.

> - Xavier Leroy


Benedikt