The OCaml Community (aka back from the Developer Days)

The OCaml Community (aka back from the Developer Days)

[David Teller]

    Dear list,

 During yesterday's OCaml Developer Day, a few important points have
been discussed. First and foremost, due to extremely limited manpower,
Inria does not intend to expand on the current OCaml distribution, nor
even to be in charge of an end-user distribution. Rather, Inria would
concentrate on the core language, in a distribution possibly smaller
than the current tarball, while the community should be in charge of
things such as
* a standard library distribution (e.g. ExtLib + Camomile + LablGtk
+ ... )
* binaries & installers
* testing
* code repositories (à la CPAN)
* deciding standard practices (e.g. Unicode) 
* expanding the platform (e.g. development environments, DSLs)
* maintaining FAQs and tutorials
* evangelism...

 How and when all this should happen needs to be discussed. One tool for
these discussions is the current mailing-list. Another tool is the Cocan
Wiki ( http://www.cocan.org ).

 One important thing: every task needs manpower. So please consider
volunteering.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] The OCaml Community (aka back from the Developer Days)

[Oliver Bandel]

Hi!

Zitat von David Teller <David.Teller@univ-orleans.fr>:

>     Dear list,
>
>  During yesterday's OCaml Developer Day, a few important points have
> been discussed. First and foremost, due to extremely limited
> manpower,
> Inria does not intend to expand on the current OCaml distribution,
> nor
> even to be in charge of an end-user distribution. Rather, Inria would
> concentrate on the core language, in a distribution possibly smaller
> than the current tarball, while the community should be in charge of
> things such as
> * a standard library distribution (e.g. ExtLib + Camomile + LablGtk
> + ... )
[...]

I'm not clear if I understand you correctly.

Would that mean that the standard-libs will be thrown off the
OCaml-distribution, and the bare compiler will be available
from INRIA?
All other things are coming from the "community"?

If so, I would not be happy about it.

I have no problem with the standard-lib as it is now.
Every person who wants to use extlib and such things,
can use it, but nobody must use it.
I prefer the standard distribution.
Possibly, when I decide to use extlib or other things,
I can do, but it's my choice.

If the currently distributed OCaml distribution would
be split into the core compiler and external libs,
then the Core-distribution alone does not help so much.

One plus of OCaml's distribution as it is now, is, that it compiles good
out of the box. One tgz-package and all is well.

when things are split up to many packages, this makes
a lot of trouble in installation - a thing, which I do not like.
I'm a prigrammer, not an administrator, and so I prefer
easy installation.
If I need extras, I CAN use them, but I can stay with the
standard-distribution, and all works well.

What, if different external libs are not fitting together?
This may bring a lot of installation-annoyance.






> * binaries & installers
> * testing
> * code repositories (Ã  la CPAN)

Yes, a CPAN-like thing would be good.

IMHO, when such a CPAN-like thing and installation-tools
are developed and are tested very well, one can decide
to make a decision like throwing out some things....
...if they can be installed easy then in thsi way...
... but even then things might brake.

But without such things like CPAN-like archives,
throwing out the necessary things, is a NONO. IMHO.

So I hope I have understand you not correctly.


> * deciding standard practices (e.g. Unicode)
> * expanding the platform (e.g. development environments, DSLs)
> * maintaining FAQs and tutorials

The reference manual for the OCaml as it is now,
IMHO should be done more verbose and up-to-date.
I think on the OCaml-C-part when writing this sentence...


> * evangelism...

I try to avoid this more and more... I already have convinced some
people, but since a while I started to avoid such evangelism
and better concentrate on my own... so I will use it,
if possible; if others don't want, they can use Java or Perl. ;-)



>
> How and when all this should happen needs to be discussed. One tool
> for
> these discussions is the current mailing-list. Another tool is the
> Cocan
> Wiki ( http://www.cocan.org ).
>
>  One important thing: every task needs manpower. So please consider
> volunteering.
[...]

I consider it, but I hope that OCaml will stay a powerful
tool that can easily be installed in the future too.
To have a patchwork of core-compiler and many seperated
libraries is not really fine, if it increases the necessary
administration efforts.

Also I think that INRIA is taking care of their code very well;
I have seen a lot of tools and libraries of the community, which
are NOT well developed. In principal I agree on the bazaar-method,
but dogmatic praying for it is nonsense. At certain points,
IMHO it's good to have a cathedral; at least in the case of OCaml
I see that it's not that bad.

So, I hope changes will be done carefully, so that
OCaml will stay safe/secure/reliable and easy to install.


Ciao,
   Oliver

Re: [Caml-list] The OCaml Community (aka back from the Developer Days)

[David Teller]

On Mon, 2008-01-28 at 01:38 +0100, Oliver Bandel wrote:
> Hi!
> I'm not clear if I understand you correctly.
> 
> Would that mean that the standard-libs will be thrown off the
> OCaml-distribution, and the bare compiler will be available
> from INRIA?
> All other things are coming from the "community"?
> 
> If so, I would not be happy about it.

>From what I understand, what is commonly regarded as the standard libs
would not be thrown off the distribution. On the other hands, things
like LablTk or OCamlBrowser might be considered for separate
distribution.

> I have no problem with the standard-lib as it is now.
> Every person who wants to use extlib and such things,
> can use it, but nobody must use it.
> I prefer the standard distribution.
> Possibly, when I decide to use extlib or other things,
> I can do, but it's my choice.
> 
> If the currently distributed OCaml distribution would
> be split into the core compiler and external libs,
> then the Core-distribution alone does not help so much.
> 
> One plus of OCaml's distribution as it is now, is, that it compiles good
> out of the box. One tgz-package and all is well.
> 
> when things are split up to many packages, this makes
> a lot of trouble in installation - a thing, which I do not like.
> I'm a prigrammer, not an administrator, and so I prefer
> easy installation.
> If I need extras, I CAN use them, but I can stay with the
> standard-distribution, and all works well.

Let me rephrase the idea.
At the moment, OCaml follows a model comparable to the JDK:
* One True Distribution
* every single file in the distribution is managed by INRIA (e.g. at the
moment, that .5 person full-time)
* bug reports are managed by INRIA
* nothing from the distribution may be fixed or improved by
third-parties.

The opposite model is the Linux model:
* a small number of developers concentrate on the kernel
* the kernel may be downloaded by itself although that's only
interesting for few people
* a large number of developers work on everything besides the kernel
* yet other developers consider the work of the previous group, test it,
manage and turn it into distributions
* most people don't even know that the kernel may be downloaded alone,
because they choose from a distribution.

The idea, here, is to *eventually* move from a JDK model to a Linux
model. Large steps have already been undertaken in that direction, with
GODI, the Debian packages, the Fedora packages, etc. The next step would
be to make this the official way of getting OCaml for the end-user. Of
course, this requires solving a number of problems, such as Windows
binaries, etc.

> What, if different external libs are not fitting together?
> This may bring a lot of installation-annoyance.

Well, that's part of the difficulties :)

> > * binaries & installers
> > * testing
> > * code repositories (Ã  la CPAN)
> 
> Yes, a CPAN-like thing would be good.

CPAN-like things are being discussed. Sylvain Le Gall has ideas and some
of the infrastructure ready, so we're waiting for him to start a thread
on this subject.

(I hope I answered your other concerns above)

> > * deciding standard practices (e.g. Unicode)
> > * expanding the platform (e.g. development environments, DSLs)
> > * maintaining FAQs and tutorials
> 
> The reference manual for the OCaml as it is now,
> IMHO should be done more verbose and up-to-date.
> I think on the OCaml-C-part when writing this sentence...

Well, don't hesitate to start your own thread on this subject whenever
we have bootstrapped the process :)

> > * evangelism...
> 
> I try to avoid this more and more... I already have convinced some
> people, but since a while I started to avoid such evangelism
> and better concentrate on my own... so I will use it,
> if possible; if others don't want, they can use Java or Perl. ;-)

Well, the main point was that INRIA isn't in charge of evangelism. 

> So, I hope changes will be done carefully, so that
> OCaml will stay safe/secure/reliable and easy to install.

Well, I only have good things to say about installing OCaml in Debian or
GODI.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: The OCaml Community (aka back from the Developer Days)

[Sylvain Le Gall]

On 28-01-2008, Oliver Bandel <oliver@first.in-berlin.de> wrote:
> Hi!
>
> Zitat von David Teller <David.Teller@univ-orleans.fr>:
>
>>     Dear list,
>>
>>  During yesterday's OCaml Developer Day, a few important points have
>> been discussed. First and foremost, due to extremely limited
>> manpower,
>> Inria does not intend to expand on the current OCaml distribution,
>> nor
>> even to be in charge of an end-user distribution. Rather, Inria would
>> concentrate on the core language, in a distribution possibly smaller
>> than the current tarball, while the community should be in charge of
>> things such as
>> * a standard library distribution (e.g. ExtLib + Camomile + LablGtk
>> + ... )
> [...]
>
> I'm not clear if I understand you correctly.
>
> Would that mean that the standard-libs will be thrown off the
> OCaml-distribution, and the bare compiler will be available
> from INRIA?
> All other things are coming from the "community"?
>
> If so, I would not be happy about it.
>
> I have no problem with the standard-lib as it is now.

I think we don't have discuss about dropping what is currently in the
standard library. INRIA will keep everything. The only thing, Xavier has
told us is that they don't wish to integrate new things, because they
don't have the manpower to do it. In other words, don't expect to have a
big ocaml distribution with OCaml compiler and a very big standard
library + a lot of tools. INRIA will try to keep ocaml maintainable by
keeping the size of the whole as small as possible.

(well to my mind, we should throw it, but this is not the INRIA point of
view)

> Every person who wants to use extlib and such things,
> can use it, but nobody must use it.
> I prefer the standard distribution.
> Possibly, when I decide to use extlib or other things,
> I can do, but it's my choice.
>
> If the currently distributed OCaml distribution would
> be split into the core compiler and external libs,
> then the Core-distribution alone does not help so much.
>
> One plus of OCaml's distribution as it is now, is, that it compiles good
> out of the box. One tgz-package and all is well.
>
> when things are split up to many packages, this makes
> a lot of trouble in installation - a thing, which I do not like.
> I'm a prigrammer, not an administrator, and so I prefer
> easy installation.
> If I need extras, I CAN use them, but I can stay with the
> standard-distribution, and all works well.
>
> What, if different external libs are not fitting together?
> This may bring a lot of installation-annoyance.
>
>

Gerd Stolpman give us a good talk about GODI. This is a very good start
for solving a lot of problem (including external libs problem).

>
>
>
>
>> * binaries & installers
>> * testing
>> * code repositories (Ã  la CPAN)
>
> Yes, a CPAN-like thing would be good.
>
> IMHO, when such a CPAN-like thing and installation-tools
> are developed and are tested very well, one can decide
> to make a decision like throwing out some things....
> ...if they can be installed easy then in thsi way...
> ... but even then things might brake.
>
> But without such things like CPAN-like archives,
> throwing out the necessary things, is a NONO. IMHO.
>
> So I hope I have understand you not correctly.
>
>

Nobody will thrown the standard library.

>> * deciding standard practices (e.g. Unicode)
>> * expanding the platform (e.g. development environments, DSLs)
>> * maintaining FAQs and tutorials
>
> The reference manual for the OCaml as it is now,
> IMHO should be done more verbose and up-to-date.
> I think on the OCaml-C-part when writing this sentence...
>
>

Regards,
Sylvain Le Gall

Re: The OCaml Community (aka back from the Developer Days)

[Sylvain Le Gall]

On 28-01-2008, David Teller <David.Teller@univ-orleans.fr> wrote:
> On Mon, 2008-01-28 at 01:38 +0100, Oliver Bandel wrote:
>> Yes, a CPAN-like thing would be good.
>
> CPAN-like things are being discussed. Sylvain Le Gall has ideas and some
> of the infrastructure ready, so we're waiting for him to start a thread
> on this subject.
>

Indeed, i hope i will be able to announce soon the availability of a
GForge for OCaml.

Concerning CPAN-like infrastructure, i think we should go the GODI way.
The most simple way to do it is to simply create a repository to
"upload" all tar.gz...

I think this is the only really missing thing with GODI. 

This point need more discussion. I am studying the PAUSE website to
understand more clearly what this is all about.

Regards,
Sylvain Le Gall

Re: [Caml-list] The OCaml Community (aka back from the Developer Days)

[Romain Beauxis]

Le Sunday 27 January 2008 14:09:22 David Teller, vous avez écrit :
>     Dear list,

	Hi !

>  During yesterday's OCaml Developer Day, a few important points have
> been discussed. First and foremost, due to extremely limited manpower,
> Inria does not intend to expand on the current OCaml distribution, nor
> even to be in charge of an end-user distribution. Rather, Inria would
> concentrate on the core language, in a distribution possibly smaller
> than the current tarball, while the community should be in charge of
> things such as
> * a standard library distribution (e.g. ExtLib + Camomile + LablGtk
> + ... )
> * binaries & installers
> * testing
> * code repositories (à la CPAN)
> * deciding standard practices (e.g. Unicode)
> * expanding the platform (e.g. development environments, DSLs)
> * maintaining FAQs and tutorials
> * evangelism...
>
>  How and when all this should happen needs to be discussed. One tool for
> these discussions is the current mailing-list. Another tool is the Cocan
> Wiki ( http://www.cocan.org ).
>
>  One important thing: every task needs manpower. So please consider
> volunteering.

Sorry I couldn't attempt to the meeting, so perhaps my point has already been 
discussed..

While I agree it's generally a good idea to rely on the community for 
improvements, I think there's a wide difference between the lack of manpower 
and a community driven organisation.

In particular, if the work are to be joined together, there shall be at some 
point a concrete collaboration between INRIA and the communauty.

It does not mean hiring people, but letting contributors participate in the 
core code too. 
Because, if we say extensions are to be maintained by a community and then we 
need to wait and be confirmed by INRIA for each change that interacts with 
the core, then it might be a loss of energy for both groups, including 
frustration...

Another question is who will provide machines and means to acheive it.
In particular, a repository à la CPAN for modules would be a great thing, but 
it would have to be supported by some structure...

Not that I suspect any problem for now, but I think this has to be stated 
clearly somewhere.


Romain

Re: The OCaml Community (aka back from the Developer Days)

[Sylvain Le Gall]

On 28-01-2008, Romain Beauxis <toots@rastageeks.org> wrote:
> Le Sunday 27 January 2008 14:09:22 David Teller, vous avez écrit :
>
> Another question is who will provide machines and means to acheive it.
> In particular, a repository à la CPAN for modules would be a great thing, but 
> it would have to be supported by some structure...
>

Indeed, you miss one point: my company will provide resource, if needed
for it. 

For now, the computer is hired (OVH SuperPlan 08) but i don't have
enough time to set it up.

I only plan to provide a GForge/planets/SCM repository for now. But in
the future, if anything else is required, i will be able to provide more
things to it.

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Jon Harrop]

On Monday 28 January 2008 13:35:34 Sylvain Le Gall wrote:
> I think we don't have discuss about dropping what is currently in the
> standard library. INRIA will keep everything.
> ...
> Nobody will thrown the standard library.

So we cannot fix the stdlib?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Romain Beauxis]

Le Monday 28 January 2008 15:42:15 Sylvain Le Gall, vous avez écrit :
> On 28-01-2008, Romain Beauxis <toots@rastageeks.org> wrote:
> > Le Sunday 27 January 2008 14:09:22 David Teller, vous avez écrit :
> >
> > Another question is who will provide machines and means to acheive it.
> > In particular, a repository à la CPAN for modules would be a great thing,
> > but it would have to be supported by some structure...
>
> Indeed, you miss one point: my company will provide resource, if needed
> for it.
>
> For now, the computer is hired (OVH SuperPlan 08) but i don't have
> enough time to set it up.
>
> I only plan to provide a GForge/planets/SCM repository for now. But in
> the future, if anything else is required, i will be able to provide more
> things to it.

Wouldn't it be better to define a real structure where your company and others 
may take part ?

For instance, kernel.org is run by a non-profit organisation, see: 
http://www.kernel.org/nonprofit.html

The fact is that, if we don't setup strong and clear definitions of who's in 
charge of what or don't define a common head for the community, what will 
happen if any of the involved company/hacker/.... decide to split and 
continue alone, or simply to shutdown one machine, or claim copyright, etc...

Again, I don't suspect any bad intention, but this is the only way to prevent 
them, isn't it ?


Romain

Re: The OCaml Community (aka back from the Developer Days)

[Sylvain Le Gall]

On 28-01-2008, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 28 January 2008 13:35:34 Sylvain Le Gall wrote:
>> I think we don't have discuss about dropping what is currently in the
>> standard library. INRIA will keep everything.
>> ...
>> Nobody will thrown the standard library.
>
> So we cannot fix the stdlib?

Yep, this is what is called "bug compatible" library... But you can
create one on your own and remove the one from INRIA (hints
-nopervasives on your compiler command line).

Maybe you can also send patch to INRIA.

Regards,
Sylvain Le Gall

Re: The OCaml Community (aka back from the Developer Days)

[Sylvain Le Gall]

Hello,

On 28-01-2008, Romain Beauxis <toots@rastageeks.org> wrote:
> Le Monday 28 January 2008 15:42:15 Sylvain Le Gall, vous avez écrit :
>> On 28-01-2008, Romain Beauxis <toots@rastageeks.org> wrote:
>> > Le Sunday 27 January 2008 14:09:22 David Teller, vous avez écrit :
>> >
>> > Another question is who will provide machines and means to acheive it.
>> > In particular, a repository à la CPAN for modules would be a great thing,
>> > but it would have to be supported by some structure...
>>
>> Indeed, you miss one point: my company will provide resource, if needed
>> for it.
>>
>> For now, the computer is hired (OVH SuperPlan 08) but i don't have
>> enough time to set it up.
>>
>> I only plan to provide a GForge/planets/SCM repository for now. But in
>> the future, if anything else is required, i will be able to provide more
>> things to it.
>
> Wouldn't it be better to define a real structure where your company and others 
> may take part ?
>
> For instance, kernel.org is run by a non-profit organisation, see: 
> http://www.kernel.org/nonprofit.html
>
> The fact is that, if we don't setup strong and clear definitions of who's in 
> charge of what or don't define a common head for the community, what will 
> happen if any of the involved company/hacker/.... decide to split and 
> continue alone, or simply to shutdown one machine, or claim copyright, etc...
>
> Again, I don't suspect any bad intention, but this is the only way to prevent 
> them, isn't it ?
>

I think we should great an "association loi 1901". I was thinking of
doing so... 

But you should know that most of the time 

<quote>
> company/hacker/....  decide to split and 
> continue alone, or simply to shutdown one machine, or claim copyright,
> etc...
</quote>

happens also with an organization. This kind of organization needs
manpower which are really provided by one or two people. This kind of
things dies as soon as only one of them decide to leave...

In other words, having an organization that defines who is in charge
won't provide stability or prevent people from doing stupid thing ;-)

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Romain Beauxis]

Le Monday 28 January 2008 16:49:28 Sylvain Le Gall, vous avez écrit :
> I think we should great an "association loi 1901". I was thinking of
> doing so...

Good !

> But you should know that most of the time
>
> <quote>
>
> > company/hacker/....  decide to split and
> > continue alone, or simply to shutdown one machine, or claim copyright,
> > etc...
>
> </quote>
>
> happens also with an organization. This kind of organization needs
> manpower which are really provided by one or two people. This kind of
> things dies as soon as only one of them decide to leave...
>
> In other words, having an organization that defines who is in charge
> won't provide stability or prevent people from doing stupid thing ;-)


Sure, but a seperate organisation has the legitimity to rule out issues when 
they happen...


Romain

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Andrej Bauer]

Sylvain Le Gall wrote:
> I think this is the only really missing thing with GODI. 

That and somewhat saner key bindings (other than 'n' and 'p'), say, how 
about being able to search among the 100+ packages?

Please do not misunderstand me. I am quite happy with GODI. It makes my 
life much simpler. I stopped using Debian-based ocaml a long time ago in 
favor of GODI.

Andrej

Re: [Caml-list] The OCaml Community (aka back from the Developer Days)

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hear, hear.  I cannot express how happy I am to hear a move towards the Linux 
model.  Not that INRIA has done a bad job, but they have limited resources 
and the Linux model provides a fix -- a way to leverage the community, an 
opportunity for us to give back =]

Peng

On Monday 28 January 2008 06:27:41 am David Teller wrote:
> Let me rephrase the idea.
> At the moment, OCaml follows a model comparable to the JDK:
> * One True Distribution
> * every single file in the distribution is managed by INRIA (e.g. at the
> moment, that .5 person full-time)
> * bug reports are managed by INRIA
> * nothing from the distribution may be fixed or improved by
> third-parties.
>
> The opposite model is the Linux model:
> * a small number of developers concentrate on the kernel
> * the kernel may be downloaded by itself although that's only
> interesting for few people
> * a large number of developers work on everything besides the kernel
> * yet other developers consider the work of the previous group, test it,
> manage and turn it into distributions
> * most people don't even know that the kernel may be downloaded alone,
> because they choose from a distribution.
>
> The idea, here, is to *eventually* move from a JDK model to a Linux
> model. Large steps have already been undertaken in that direction, with
> GODI, the Debian packages, the Fedora packages, etc. The next step would
> be to make this the official way of getting OCaml for the end-user. Of
> course, this requires solving a number of problems, such as Windows
> binaries, etc.
>
> CPAN-like things are being discussed. Sylvain Le Gall has ideas and some
> of the infrastructure ready, so we're waiting for him to start a thread
> on this subject.
>
> Well, I only have good things to say about installing OCaml in Debian or
> GODI.
>
> Cheers,
>  David


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHng/5fIRcEFL/JewRAp34AJ9deG7nSz+BkfsYKEpSuyEbhSwPJwCfQ1Cs
EcIgFYovZdQ4T59SYlhSFjk=
=MbDT
-----END PGP SIGNATURE-----

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Jon Harrop]

On Monday 28 January 2008 15:43:22 Sylvain Le Gall wrote:
> On 28-01-2008, Jon Harrop <jon@ffconsultancy.com> wrote:
> > On Monday 28 January 2008 13:35:34 Sylvain Le Gall wrote:
> >> I think we don't have discuss about dropping what is currently in the
> >> standard library. INRIA will keep everything.
> >> ...
> >> Nobody will thrown the standard library.
> >
> > So we cannot fix the stdlib?
>
> Yep, this is what is called "bug compatible" library... But you can
> create one on your own and remove the one from INRIA (hints
> -nopervasives on your compiler command line).

Then I don't understand how this improves upon the current situation.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Hezekiah M. Carty]

On Jan 28, 2008 2:49 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 28 January 2008 15:43:22 Sylvain Le Gall wrote:
> > On 28-01-2008, Jon Harrop <jon@ffconsultancy.com> wrote:
> > > On Monday 28 January 2008 13:35:34 Sylvain Le Gall wrote:
> > >> I think we don't have discuss about dropping what is currently in the
> > >> standard library. INRIA will keep everything.
> > >> ...
> > >> Nobody will thrown the standard library.
> > >
> > > So we cannot fix the stdlib?
> >
> > Yep, this is what is called "bug compatible" library... But you can
> > create one on your own and remove the one from INRIA (hints
> > -nopervasives on your compiler command line).
>
> Then I don't understand how this improves upon the current situation.
>

My understanding is that the benefits would come from having a richer,
community developed "official" OCaml distribution.  So the stdlib
would stay in place, but extra items would be included as well.  For
example, package ExtLib and some commonly useful Camlp4 extensions
along with the distribution .tar.gz/.exe/.dmg.  If I understood the
meeting transcription in IRC, the official OCaml folks at INRIA would
bless this as the proper way to get and install OCaml once the
community structure is in place.

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Jon Harrop]

On Monday 28 January 2008 20:16:17 you wrote:
> My understanding is that the benefits would come from having a richer,
> community developed "official" OCaml distribution.  So the stdlib
> would stay in place, but extra items would be included as well.

Ah! So we can fix the stdlib?

Perhaps I should clarify what I mean: we can provide missing functionality, 
make functions tail recursive and optimize them.

> For 
> example, package ExtLib and some commonly useful Camlp4 extensions
> along with the distribution .tar.gz/.exe/.dmg.  If I understood the
> meeting transcription in IRC, the official OCaml folks at INRIA would
> bless this as the proper way to get and install OCaml once the
> community structure is in place.

Ok. Even if the community doesn't control the language, I still think this is 
a step in the right direction.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Hezekiah M. Carty]

On Jan 28, 2008 3:35 PM, Loup Vaillant <loup.vaillant@gmail.com> wrote:
> 2008/1/28, Hezekiah M. Carty <hcarty@atmos.umd.edu>:
> > On Jan 28, 2008 2:49 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > > On Monday 28 January 2008 15:43:22 Sylvain Le Gall wrote:
> > > > On 28-01-2008, Jon Harrop <jon@ffconsultancy.com> wrote:
> > > > > On Monday 28 January 2008 13:35:34 Sylvain Le Gall wrote:
> > > > >> I think we don't have discuss about dropping what is currently in the
> > > > >> standard library. INRIA will keep everything.
> > > > >> ...
> > > > >> Nobody will thrown the standard library.
> > > > >
> > > > > So we cannot fix the stdlib?
> > > >
> > > > Yep, this is what is called "bug compatible" library... But you can
> > > > create one on your own and remove the one from INRIA (hints
> > > > -nopervasives on your compiler command line).
> > >
> > > Then I don't understand how this improves upon the current situation.
> > >
> >
> > My understanding is that the benefits would come from having a richer,
> > community developed "official" OCaml distribution.  So the stdlib
> > would stay in place, but extra items would be included as well.  For
> > example, package ExtLib and some commonly useful Camlp4 extensions
> > along with the distribution .tar.gz/.exe/.dmg.  If I understood the
> > meeting transcription in IRC, the official OCaml folks at INRIA would
> > bless this as the proper way to get and install OCaml once the
> > community structure is in place.
>
> Could a patched version of the stdlib and/or compiler could be bundled
> in such a distribution? This is the only way to have a tail recursive
> List.map, for instance.
>
> I suppose working around the license can be done without too much
> hassle? If I understand, the distro maker have to distribute the
> unmodified sources and the patches, so the user have to first apply
> the patches, then compile whats need to be (possibly using a script to
> automate the whole process).
>
> Loup
>

The library license is LGPL, so the stdlib could be changed in the
distribution without extra licensing trouble.  However, that is
probably not the way to go if we want to maintain bug-for-bug
compatibility.  For the example you mentioned, ExtLib already has a
tail recursive List.map, so if that were included it (or something
similar) in the official distribution then developers will know that
"open ExtList" will provide them with a tail recursive List.map
implementation without the end user having to install libraries out of
the official distribution.

I do not know the details of the compiler license (QPL) but I think
modifications would have to be distributed as patches and then applied
on the user's end.  I also do not know how this would affect binary
distributions of OCaml.

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Hezekiah M. Carty]

On Jan 28, 2008 3:35 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 28 January 2008 20:16:17 you wrote:
> > My understanding is that the benefits would come from having a richer,
> > community developed "official" OCaml distribution.  So the stdlib
> > would stay in place, but extra items would be included as well.
>
> Ah! So we can fix the stdlib?
>
> Perhaps I should clarify what I mean: we can provide missing functionality,
> make functions tail recursive and optimize them.
>
> > For
> > example, package ExtLib and some commonly useful Camlp4 extensions
> > along with the distribution .tar.gz/.exe/.dmg.  If I understood the
> > meeting transcription in IRC, the official OCaml folks at INRIA would
> > bless this as the proper way to get and install OCaml once the
> > community structure is in place.
>
> Ok. Even if the community doesn't control the language, I still think this is
> a step in the right direction.
>

There are IRC transcripts available here:
http://tunes.org/~nef/logs/ocaml/08.01.26 which may clarify things
somewhat.

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

Alterlib? (was "Re: The OCaml Community")

[Dario Teixeira]

> My understanding is that the benefits would come from having a richer,
> community developed "official" OCaml distribution.  So the stdlib
> would stay in place, but extra items would be included as well.  For
> example, package ExtLib and some commonly useful Camlp4 extensions
> along with the distribution .tar.gz/.exe/.dmg.  If I understood the
> meeting transcription in IRC, the official OCaml folks at INRIA would
> bless this as the proper way to get and install OCaml once the
> community structure is in place.

Hi,

For compatibility reasons, Stdlib must be part of any standard Ocaml
distribution for the foreseeable future.  However, this does not
necessarily mean that the only community solution must be to provide
an ExtLib that complements Stdlib.  If it is felt that Stdlib+Extlib
does not fit well together (different conventions, etc), there is
always the option of creating "from scratch" a self-contained Alterlib
that incorporates everything you would wish from a standard library.
(note that I've written "from scratch" between commas because a lot
of code from Extlib and other open-source libraries could be reused).

Users who have heavily invested in Stdlib could continue using it;
others, however, could very well choose to ditch it altogether and
make sole use of Alterlib (with "-nopervasives", of course).

In short, here are the options:

a) modify Stdlib to suit the community's needs (complicated due
   to copyright issues and because INRIA does not have the manpower
   to effectively maintain all the additions);

b) keep Stdlib and put all the community's needs into Extlib
   (in a sense this the current situation; has the advantage of
   being straightforward; has the disadvantage that the APIs
   might not always go well together);

c) keep stdlib for compatibility reasons (INRIA's tarball must
   always include it), but provide a community built Alterlib
   that reimplements what's good about Stdlib together with
   stuff currently on Extlib (requires more work, but may
   result in a more modern, more consistent library)

Do I read the situation correctly?

Kind regards,
Dario Teixeira



      ___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

Re: [Caml-list] Alterlib? (was "Re: The OCaml Community")

[blue storm]

a) doesn't seem to be an option :
the INRIA won't include in stdlib things they don't want to maintain,
and they don't want to maintain anything more.

I don't think point c) is a really good idea : most people are quite
comfortable with Stdlib now. Do you have *really* good reasons to
create an interface-incompatible library ?
I don't think so : lots of people have expressed concern for the lack
of something in the Stdlib, but i haven't seen anybody actually
complaining about one of the provided functions (except for the
tail-rec thing, wich isn't an incompatible change).
If all the change you want to make are compatible (either addition of
plain new functions/modules, or interface-compatible changes of
existing ones), then i think the "overriding" model of Extlib is fine.
What does -nopervasives give us in that case ?

On 1/28/08, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> > My understanding is that the benefits would come from having a richer,
> > community developed "official" OCaml distribution.  So the stdlib
> > would stay in place, but extra items would be included as well.  For
> > example, package ExtLib and some commonly useful Camlp4 extensions
> > along with the distribution .tar.gz/.exe/.dmg.  If I understood the
> > meeting transcription in IRC, the official OCaml folks at INRIA would
> > bless this as the proper way to get and install OCaml once the
> > community structure is in place.
>
> Hi,
>
> For compatibility reasons, Stdlib must be part of any standard Ocaml
> distribution for the foreseeable future.  However, this does not
> necessarily mean that the only community solution must be to provide
> an ExtLib that complements Stdlib.  If it is felt that Stdlib+Extlib
> does not fit well together (different conventions, etc), there is
> always the option of creating "from scratch" a self-contained Alterlib
> that incorporates everything you would wish from a standard library.
> (note that I've written "from scratch" between commas because a lot
> of code from Extlib and other open-source libraries could be reused).
>
> Users who have heavily invested in Stdlib could continue using it;
> others, however, could very well choose to ditch it altogether and
> make sole use of Alterlib (with "-nopervasives", of course).
>
> In short, here are the options:
>
> a) modify Stdlib to suit the community's needs (complicated due
>    to copyright issues and because INRIA does not have the manpower
>    to effectively maintain all the additions);
>
> b) keep Stdlib and put all the community's needs into Extlib
>    (in a sense this the current situation; has the advantage of
>    being straightforward; has the disadvantage that the APIs
>    might not always go well together);
>
> c) keep stdlib for compatibility reasons (INRIA's tarball must
>    always include it), but provide a community built Alterlib
>    that reimplements what's good about Stdlib together with
>    stuff currently on Extlib (requires more work, but may
>    result in a more modern, more consistent library)
>
> Do I read the situation correctly?
>
> Kind regards,
> Dario Teixeira
>
>
>
>       ___________________________________________________________
> Support the World Aids Awareness campaign this month with Yahoo! For Good
> http://uk.promotions.yahoo.com/forgood/
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Markus Mottl]

Since there were quite a lot of positive comments about Godi lately, I
think it is also necessary to point out some of its significant
drawbacks.  We (Jane Street Capital) have been using Godi internally
for quite a while, and I have to admit that we are less than thrilled
by it and are planning to phase it out from our development
environment.  Following is a short description of what seem to be the
major problems.

Users of package management systems usually fall into one (or more) of
these roles:

  * Software developers
  * Package maintainers
  * Installation administrators
  * Package users

In our experience the only role that is sufficiently well-supported by
Godi is the one of the package user.  It essentially boils down to
using ocamlfind, which works fine for that purpose.  The majority of
OCaml users belongs to this group most of the time, which probably
explains why Godi caught on so well.

However, the other roles are much worse off.  It seems one design
decision of Godi was to separate software developers and package
maintainers.  In practice, however, package maintainers are usually
also the developers, and they are most often also package users.  If I
want to roll out and work with an updated Godi-package, I have to jump
through several hoops before I can do so: upload my updated tarball to
my webserver, update the package metadata in the Godi SVN-repository,
point my browser to the Godi website to update the Godi distribution,
go to my local Godi-installation, update and recompile the package,
and finally, when I try to use it, I may find out that I had made a
mistake somewhere and have to start all over.  The build system used
by Godi, which is based on NetBSD's package management, is arcane to
say the least.  I still don't quite understand how to e.g. correctly
make packages check for C-library dependencies, etc.

Administrating a Godi installation is no easy task either.  The user
interface seems quite cumbersome and hard to use.  Furthermore, it is
not easy to integrate libraries that are not in Godi (as packages).
They need to be rebuilt, too, when their dependencies get updated, but
automating this task is essentially only possible by jumping through
the hoops of making packages and becoming their maintainer.  A task
that many would rather not take over and hardly makes sense if there
is no intention to release such packages to the general public in the
first place.

The question now is how to solve these issues, and it's clear that
this would require a fairly significant development effort.

As a software developer and package maintainer, I'd ideally like to be
able to work on a source tree containing the complete code of all
packages (and their dependencies), make changes wherever I want (fix
bugs, add features, add new libraries, etc.), share patches or full
versions with other maintainers, and all of this with a minimum amount
of overhead.  Since Godi only tracks dependencies between packages, it
is not possible to just update code and let the build system figure
out what needs to be recompiled.  One needs to build new packages
instead, which is way too much effort.  As installation administrator
I'd like to be able to use a straightforward user interface and easily
add 3rd party libraries without having to manually make sure that
dependencies are not violated.

It is still a point of discussion at our company how to replace Godi,
and also how we could find a solution that would integrate well with
the OCaml-community.  We have developed a fair amount of
infrastructure to improve our team productivity (we have around 20
full time developers now working in three different locations) by
lowering turnaround times associated with code changes.  The use of
distributed version control, compile daemons and omake has made it
very easy for us to share code that is guaranteed to compile and
allows making modifications quickly with a minimum amount of time
required for recompilations.

It seems likely that focusing on a high degree of standardization
around the usage of software development tools (which version control
to use, how to guarantee compilability, what build tools to use,
standards enforcing easy combination and modularity of build
processes) would lower development barriers and thus boost the
productivity of the OCaml community.  But it seems rather unlikely to
most of us that Godi will be a suitable foundation for moving forward.
 We greatly appreciate Gerd's tireless efforts to contribute tools
like Godi, which is a lot of hard work that nobody else wanted to do
before.  We have certainly benefited from it in the past and hope that
a new approach will alleviate the problems that Godi-developers often
run into.

Best regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Gerd Stolpmann]

Dear Markus,

I'm a bit speechless, and admit I have really problems formulating an
appropriate response. I know that companies tend to separate themselves
from others, since they are finally only a group of people sitting
together and working on their own agenda. So the discussion within
companies usually has a lot of specifics which cannot be understood from
the outside.

Nevertheless it is sometimes important to recall some facts that might
have been overlooked in the company-internal discussion.

1. GODI is meant as an effort to bundle the activities of the community.
It is not a commercial offer, and there is no customer support
complaints can be directed at. If you want to improve it, the only way
is to spend time and energy, and to enter a constructive discussion on
godi-list. It is a pity that nobody at Jane Street wants to do this.

2. As I'm the guy who mainly developed the core of GODI I can tell you
that every hour I work on GODI is an hour I cannot work for one of my
customers. So GODI produces opportunity costs for me. From that point of
view I cannot understand a (probably) rich company that profited from
this project for free, and is unwilling to share some of the costs.
There is an economy behind free software, and Jane Street seems not to
have understood it.

3. Jane Street announced several times that they wanted to release
software into the OSS world. Nothing happened. From that experience I
think your "new approach" is also nothing but vaporware.

Sorry for the direct language, but you provoked it. It is a pity to lose
Jane Street as supporter of GODI. If you still want to enter into a
constructive dialog, I'm open to it.

Gerd


Am Montag, den 28.01.2008, 19:26 -0500 schrieb Markus Mottl: 
> Since there were quite a lot of positive comments about Godi lately, I
> think it is also necessary to point out some of its significant
> drawbacks.  We (Jane Street Capital) have been using Godi internally
> for quite a while, and I have to admit that we are less than thrilled
> by it and are planning to phase it out from our development
> environment.  Following is a short description of what seem to be the
> major problems.
> 
> Users of package management systems usually fall into one (or more) of
> these roles:
> 
>   * Software developers
>   * Package maintainers
>   * Installation administrators
>   * Package users
> 
> In our experience the only role that is sufficiently well-supported by
> Godi is the one of the package user.  It essentially boils down to
> using ocamlfind, which works fine for that purpose.  The majority of
> OCaml users belongs to this group most of the time, which probably
> explains why Godi caught on so well.
> 
> However, the other roles are much worse off.  It seems one design
> decision of Godi was to separate software developers and package
> maintainers.  In practice, however, package maintainers are usually
> also the developers, and they are most often also package users.  If I
> want to roll out and work with an updated Godi-package, I have to jump
> through several hoops before I can do so: upload my updated tarball to
> my webserver, update the package metadata in the Godi SVN-repository,
> point my browser to the Godi website to update the Godi distribution,
> go to my local Godi-installation, update and recompile the package,
> and finally, when I try to use it, I may find out that I had made a
> mistake somewhere and have to start all over.  The build system used
> by Godi, which is based on NetBSD's package management, is arcane to
> say the least.  I still don't quite understand how to e.g. correctly
> make packages check for C-library dependencies, etc.
> 
> Administrating a Godi installation is no easy task either.  The user
> interface seems quite cumbersome and hard to use.  Furthermore, it is
> not easy to integrate libraries that are not in Godi (as packages).
> They need to be rebuilt, too, when their dependencies get updated, but
> automating this task is essentially only possible by jumping through
> the hoops of making packages and becoming their maintainer.  A task
> that many would rather not take over and hardly makes sense if there
> is no intention to release such packages to the general public in the
> first place.
> 
> The question now is how to solve these issues, and it's clear that
> this would require a fairly significant development effort.
> 
> As a software developer and package maintainer, I'd ideally like to be
> able to work on a source tree containing the complete code of all
> packages (and their dependencies), make changes wherever I want (fix
> bugs, add features, add new libraries, etc.), share patches or full
> versions with other maintainers, and all of this with a minimum amount
> of overhead.  Since Godi only tracks dependencies between packages, it
> is not possible to just update code and let the build system figure
> out what needs to be recompiled.  One needs to build new packages
> instead, which is way too much effort.  As installation administrator
> I'd like to be able to use a straightforward user interface and easily
> add 3rd party libraries without having to manually make sure that
> dependencies are not violated.
> 
> It is still a point of discussion at our company how to replace Godi,
> and also how we could find a solution that would integrate well with
> the OCaml-community.  We have developed a fair amount of
> infrastructure to improve our team productivity (we have around 20
> full time developers now working in three different locations) by
> lowering turnaround times associated with code changes.  The use of
> distributed version control, compile daemons and omake has made it
> very easy for us to share code that is guaranteed to compile and
> allows making modifications quickly with a minimum amount of time
> required for recompilations.
> 
> It seems likely that focusing on a high degree of standardization
> around the usage of software development tools (which version control
> to use, how to guarantee compilability, what build tools to use,
> standards enforcing easy combination and modularity of build
> processes) would lower development barriers and thus boost the
> productivity of the OCaml community.  But it seems rather unlikely to
> most of us that Godi will be a suitable foundation for moving forward.
>  We greatly appreciate Gerd's tireless efforts to contribute tools
> like Godi, which is a lot of hard work that nobody else wanted to do
> before.  We have certainly benefited from it in the past and hope that
> a new approach will alleviate the problems that Godi-developers often
> run into.
> 
> Best regards,
> Markus
> 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Stefano Zacchiroli]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Mon, Jan 28, 2008 at 02:42:15PM +0000, Sylvain Le Gall wrote:
> Indeed, you miss one point: my company will provide resource, if needed
> for it. 

Ah, great, that was not clear so far to me either.

> For now, the computer is hired (OVH SuperPlan 08) but i don't have
> enough time to set it up.

Then ask for help.

I think that in Debian we will benefit from such a central repository
too (and much more we will benefit from any standardization efforts
about how OCaml libraries are packages, distributed, ...), so I'm
personally willing to invest some of my Debian time to help you out in
this. I guess other of ours Debian OCaml maintainers colleagues will be
happy to do the same.

Also, from a management point of view, we already have a chain of trust
among us (we already share repository management elsewhere for example)
and I think this aspect would grant the OCaml community some more
assurance of fault tolerance in case you will sometime be unable to fix
something. (This, of course, assuming your company is not against this
kind of co-operation.)

What do you think?

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Markus Mottl]

Dear Gerd,

On Jan 29, 2008 8:45 AM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 1. GODI is meant as an effort to bundle the activities of the community.
> It is not a commercial offer, and there is no customer support
> complaints can be directed at. If you want to improve it, the only way
> is to spend time and energy, and to enter a constructive discussion on
> godi-list. It is a pity that nobody at Jane Street wants to do this.

It seems to me that the OCaml mailing list is an appropriate place to
discuss the future of package management systems for OCaml.  We would
certainly gladly contribute to the development of Godi, since we, too,
think that a good package management system is essential for the
success of OCaml.  It's just that we feel that the basic design of
Godi, especially it's reliance on NetBSD-like package management,
would not play out well in the long haul, because we came to the
conclusion that it is not sufficiently developer-friendly.

We don't see that as a failure on your side, because finding the right
solution to notoriously complex problems of this sort is, to a large
degree, a matter of trial and error.  It seems that the major problems
that people faced back then as package users were addressed well.
Experience taught us that better support for other roles, especially
developers, is needed, and this may require a substantially different
approach.

> 2. As I'm the guy who mainly developed the core of GODI I can tell you
> that every hour I work on GODI is an hour I cannot work for one of my
> customers. So GODI produces opportunity costs for me. From that point of
> view I cannot understand a (probably) rich company that profited from
> this project for free, and is unwilling to share some of the costs.
> There is an economy behind free software, and Jane Street seems not to
> have understood it.

I think you have to admit that you are not being fair here.  Our
company has spent a fairly significant amount of time and money on
contributing to OCaml.  Organizing the OCaml Summer Project alone has
easily cost us many tens of thousands of dollars. And that's not
counting lost developer time.

> 3. Jane Street announced several times that they wanted to release
> software into the OSS world. Nothing happened.

This, too, is not true.  We certainly haven't released as much as we
would like to, since, as you might guess, we are extremely busy making
a living of our work, too. But I think you are doing us a big disfavor
with such false remarks by disregarding contributions we have made,
newly developed libraries like Sexplib, substantially rewritten ones
(Sqlite3-bindings), feature extensions (e.g. to Lacaml), compiler
patches (e.g. function call backtraces; tons of bug reports and
fixes), etc., and there is much more, very well-tested code in the
final stage of our release process.  Note that not all our
contributions are published on our website.  We are not into
marketing.

> From that experience I think your "new approach" is also nothing but vaporware.

I haven't said anywhere that we already have a "new approach".  In
fact, I said the exact opposite, namely that we are not sure yet what
exactly a better alternative would look like.  This is the reason why
we want to contribute to the discussion, and pointing out the
downsides of existing software, too, is important to make progress.

Lets face it: the vast majority of people just want to install a few
libraries they need for their work on their research or pet projects.
Godi is perfectly fine for maintaining such environments.  But if
sharing code and collaborative work is high on your list of priorities
(as it is for large teams like ours and surely also open source
development teams), Godi seems more like an obstacle.  A more
integrated and sufficiently standardized approach that combines
version control, build systems, automated compilation and test suites,
and packaging seems necessary to really give a boost to our
productivity.

> Sorry for the direct language, but you provoked it. It is a pity to lose
> Jane Street as supporter of GODI. If you still want to enter into a
> constructive dialog, I'm open to it.

Constructive dialogs cannot only consist of positive remarks, and I'm
sure you understand that.  You have pioneered an area that nobody else
in the OCaml community had tried before, because it's hard and a lot
of work.  As much as pioneers discover fruitful areas, they also
discover parts that are not worthwhile going.  I appreciate this
effort, and I can understand your defensive and natural reaction to
our criticism.  But note that this is not a criticism of you but of
the potential of Godi as the foundation for a standardized package
management system for OCaml.

Best regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: The OCaml Community (aka back from the Developer Days)

[Sylvain Le Gall]

On 29-01-2008, Markus Mottl <markus.mottl@gmail.com> wrote:
> However, the other roles are much worse off.  It seems one design
> decision of Godi was to separate software developers and package
> maintainers.  In practice, however, package maintainers are usually
> also the developers, and they are most often also package users.  If I
> want to roll out and work with an updated Godi-package, I have to jump
> through several hoops before I can do so: upload my updated tarball to
> my webserver, update the package metadata in the Godi SVN-repository,
> point my browser to the Godi website to update the Godi distribution,
> go to my local Godi-installation, update and recompile the package,
> and finally, when I try to use it, I may find out that I had made a
> mistake somewhere and have to start all over.  The build system used
> by Godi, which is based on NetBSD's package management, is arcane to
> say the least.  I still don't quite understand how to e.g. correctly
> make packages check for C-library dependencies, etc.

I do think separation between software developers and package
maintainers are a good point. Because, if you consider that there is a
lot of distribution (talking about Linux), you will also have a lot of
different ways to do package. If you are the developper and the package
maintainer, most of the time pieces of information are only available
in the packaging metadata, because it will allow you to build as you do
in Debian/Fedora/Suse... Unfortunately, this kind of information will
automatically be missing for other distribution.

The best software developper can do about this is to provide a way to
build their package the best they can (and accept patches from
packagers). Then it would be easy to package for every distribution.

>
> As a software developer and package maintainer, I'd ideally like to be
> able to work on a source tree containing the complete code of all
> packages (and their dependencies), make changes wherever I want (fix
> bugs, add features, add new libraries, etc.), share patches or full
> versions with other maintainers, and all of this with a minimum amount
> of overhead.  Since Godi only tracks dependencies between packages, it
> is not possible to just update code and let the build system figure
> out what needs to be recompiled.  One needs to build new packages
> instead, which is way too much effort.  As installation administrator
> I'd like to be able to use a straightforward user interface and easily
> add 3rd party libraries without having to manually make sure that
> dependencies are not violated.
>

I think you have a good point of improvement here, that should not be
too complicated:
* make GODI use a directory containing uncompressed software
* prevents using a particular VCS (just consider GODI package as
 metadata)
* allow GODI to track fine changes into packages

The last point is probably the most complicated one, since we are not
yet able to do it in Debian. But i really think that this is feasable.

Using uncompressed software + GODI metadata should allow you to have a
full source tree uncompressed on your local computer. This should, maybe,
solve some of your issues.

> It is still a point of discussion at our company how to replace Godi,
> and also how we could find a solution that would integrate well with
> the OCaml-community.  We have developed a fair amount of
> infrastructure to improve our team productivity (we have around 20
> full time developers now working in three different locations) by
> lowering turnaround times associated with code changes.  The use of
> distributed version control, compile daemons and omake has made it
> very easy for us to share code that is guaranteed to compile and
> allows making modifications quickly with a minimum amount of time
> required for recompilations.
>

It would be a pity. GODI is the most advanced PM for OCaml. Contributing
to its development is something that can leverage a lot of things. I
think this should shorten the delay of creating 

> It seems likely that focusing on a high degree of standardization
> around the usage of software development tools (which version control
> to use, how to guarantee compilability, what build tools to use,
> standards enforcing easy combination and modularity of build
> processes) would lower development barriers and thus boost the
> productivity of the OCaml community.  But it seems rather unlikely to
> most of us that Godi will be a suitable foundation for moving forward.
>  We greatly appreciate Gerd's tireless efforts to contribute tools
> like Godi, which is a lot of hard work that nobody else wanted to do
> before.  We have certainly benefited from it in the past and hope that
> a new approach will alleviate the problems that Godi-developers often
> run into.
>

Talking about standardization around the usage of software development
tools will just lead to a boost of FLAMEWARE productivity. There is no
best way to do things. We should just accept any proposition and try to
make things work in most case. Believing that everybody will accept to
use the same way of developping software, is just a dream (but you are
allowed to dream).

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Kuba Ober]

> Sorry for the direct language, but you provoked it. It is a pity to lose
> Jane Street as supporter of GODI. If you still want to enter into a
> constructive dialog, I'm open to it.

I think that Markus's post was reasonably well balanced, and he presented a 
humble view from his experience. It didn't look like bashing nor 
flamethrowing to me. The facts in question can be disputed, but they really 
have nothing to do about who profits from what and who pays for what. Let's 
leave the economics out of the merit discussion -- doesn't that only make 
sense?

Cheers, Kuba

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Vincent Hanquez]

On Tue, Jan 29, 2008 at 02:45:00PM +0100, Gerd Stolpmann wrote:
> Sorry for the direct language, but you provoked it. It is a pity to lose
> Jane Street as supporter of GODI. If you still want to enter into a
> constructive dialog, I'm open to it.

Markus raises valid issues imho, so apparently not so not open.

-- 
Vincent Hanquez

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Jon Harrop]

On Wednesday 30 January 2008 13:04:06 Kuba Ober wrote:
> > Sorry for the direct language, but you provoked it. It is a pity to lose
> > Jane Street as supporter of GODI. If you still want to enter into a
> > constructive dialog, I'm open to it.
>
> I think that Markus's post was reasonably well balanced, and he presented a
> humble view from his experience. It didn't look like bashing nor
> flamethrowing to me. The facts in question can be disputed, but they really
> have nothing to do about who profits from what and who pays for what. Let's
> leave the economics out of the merit discussion -- doesn't that only make
> sense?

If I might just drag economics back in momentarily. :-)

People have mentioned "volunteers" but I think it is worth pointing out that 
this could also be run as a business, with users paying for work that they 
want done. Perhaps a system of charging customers and letting them choose 
what work and which developer would increase overall productivity and be 
relatively easy to implement?

INRIA could doubtless make a lot of money by doing this so I proposed the idea 
to Xavier but he wants to focus on research and not ordinary software 
development and maintainence, of course.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Kuba Ober]

On Wednesday 30 January 2008, Jon Harrop wrote:
> On Wednesday 30 January 2008 13:04:06 Kuba Ober wrote:
> > > Sorry for the direct language, but you provoked it. It is a pity to
> > > lose Jane Street as supporter of GODI. If you still want to enter into
> > > a constructive dialog, I'm open to it.
> >
> > I think that Markus's post was reasonably well balanced, and he presented
> > a humble view from his experience. It didn't look like bashing nor
> > flamethrowing to me. The facts in question can be disputed, but they
> > really have nothing to do about who profits from what and who pays for
> > what. Let's leave the economics out of the merit discussion -- doesn't
> > that only make sense?
>
> If I might just drag economics back in momentarily. :-)
>
> People have mentioned "volunteers" but I think it is worth pointing out
> that this could also be run as a business, with users paying for work that
> they want done. Perhaps a system of charging customers and letting them
> choose what work and which developer would increase overall productivity
> and be relatively easy to implement?
>
> INRIA could doubtless make a lot of money by doing this so I proposed the
> idea to Xavier but he wants to focus on research and not ordinary software
> development and maintainence, of course.

It would make sense as a business venture when you'd throw in some economy of 
scale. MS can sell visual studio for peanuts, and keep that business unit out 
of the red, of course because they sell so many.

For relatively small projects like OCaml, any "pay for a feature" scheme would 
necessarily be out of reach of many customers. Maybe Jane Street could afford 
to pay $100/hr consulting rate to a seasoned OCaml hacker, but for most of us 
that makes little financial sense.

I guess it's a big stride to break that small-to-mid-scale barrier. Trolltech 
had done that, and they are IMHO good technical innvoators too. If there was 
a way for some OCaml-centric business to do what Trolltech had done, it could 
probably take off and make very feature-rich OCaml environment available for 
a good price I wouldn't mind paying $1500/year for an OCaml environment that 
could run natively (as in no .net and no Cygwin dependencies) on Windows and 
Linux, and just "do the job". Qt is really nice in that regard: you only need 
the C++ compiler, and everything else is included and ready to go. It even 
builds its own build tools (qmake, moc, uic).

Cheers, Kuba

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Jon Harrop]

On Wednesday 30 January 2008 14:17:13 Kuba Ober wrote:
> It would make sense as a business venture when you'd throw in some economy
> of scale. MS can sell visual studio for peanuts, and keep that business
> unit out of the red, of course because they sell so many.

Visual Studio should be making a lot of profit. Microsoft have many commercial 
developers and it is illegal for them to sell products built using many of 
Microsoft's freely available tools. To buy decent tools for commercial 
development, you're looking at 3,000 euros. Either you're very rich, or that 
isn't "peanuts". :-)

> For relatively small projects like OCaml, any "pay for a feature" scheme
> would necessarily be out of reach of many customers. Maybe Jane Street
> could afford to pay $100/hr consulting rate to a seasoned OCaml hacker, but
> for most of us that makes little financial sense.

If I wanted to pay you to "complete" the String module, how much would you 
charge? Many suitably qualified people would be happy to earn $100 for doing 
that and, I believe, many people/companies would be willing to pay that. I'd 
much rather give people a one-off small contract paid on-line by credit card 
to solve a niggling problem that I didn't have time to fix myself than employ 
someone with tax, insurance and liability concerns. If they're good, I'll use 
them again.

Moreover, the developer could set an earnings threshold for a given task and 
many users could independently contribute to the payment. They don't pay 
until the threshold is met.

When I'm selling books like hot cakes and have more outstanding consultancy 
contracts than I can shake a stick at, I'll be more than happy to throw money 
at you to improve things. When I'm going hungry and struggling to keep my 
head above water, I'll be more than happy to solve your problems for a small 
fee. :-)

> I guess it's a big stride to break that small-to-mid-scale barrier.
> Trolltech had done that, and they are IMHO good technical innvoators too.
> If there was a way for some OCaml-centric business to do what Trolltech had
> done, it could probably take off and make very feature-rich OCaml
> environment available for a good price I wouldn't mind paying $1500/year
> for an OCaml environment that could run natively (as in no .net and no
> Cygwin dependencies) on Windows and Linux, and just "do the job". Qt is
> really nice in that regard: you only need the C++ compiler, and everything
> else is included and ready to go. It even builds its own build tools
> (qmake, moc, uic).

OCaml is not as big as TrollTech and has some annoying problems that make it 
unviable as a commercial platform in many ways but I think our company has 
shown that OCaml's commercial market is now sufficient that you can earn a 
living from it.

To be honest, I would love to be able to buy more books on OCaml (e.g. on 
LablGTK2), more software written in OCaml and libraries for OCaml and so on. 
I believe there are now tens of thousands of prospective customers out there 
for such OCaml products.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days)

[Kuba Ober]

On Wednesday 30 January 2008, Jon Harrop wrote:
> On Wednesday 30 January 2008 14:17:13 Kuba Ober wrote:
> > It would make sense as a business venture when you'd throw in some
> > economy of scale. MS can sell visual studio for peanuts, and keep that
> > business unit out of the red, of course because they sell so many.
>
> Visual Studio should be making a lot of profit. Microsoft have many
> commercial developers and it is illegal for them to sell products built
> using many of Microsoft's freely available tools. To buy decent tools for
> commercial development, you're looking at 3,000 euros. Either you're very
> rich, or that isn't "peanuts". :-)

I don't think you're prohibited from using Visual Studio Standard in 
commercial development, and that does sell for peanuts.

> If I wanted to pay you to "complete" the String module, how much would you
> charge? Many suitably qualified people would be happy to earn $100 for
> doing that and, I believe, many people/companies would be willing to pay
> that.

I'm sure as a student I'd be very happy. A professional who can choose between 
consulting hours and doing that, the person would probably choose consulting 
hours.

> I'd much rather give people a one-off small contract paid on-line by 
> credit card to solve a niggling problem that I didn't have time to fix
> myself than employ someone with tax, insurance and liability concerns. If
> they're good, I'll use them again.

Yet I doubt that professional developers who want to earn off of their work 
will pick up such projects.

> When I'm selling books like hot cakes and have more outstanding consultancy
> contracts than I can shake a stick at, I'll be more than happy to throw
> money at you to improve things. When I'm going hungry and struggling to
> keep my head above water, I'll be more than happy to solve your problems
> for a small fee. :-)

See? :)

> > I guess it's a big stride to break that small-to-mid-scale barrier.
> > Trolltech had done that, and they are IMHO good technical innvoators too.
> > If there was a way for some OCaml-centric business to do what Trolltech
> > had done, it could probably take off and make very feature-rich OCaml
> > environment available for a good price I wouldn't mind paying $1500/year
> > for an OCaml environment that could run natively (as in no .net and no
> > Cygwin dependencies) on Windows and Linux, and just "do the job". Qt is
> > really nice in that regard: you only need the C++ compiler, and
> > everything else is included and ready to go. It even builds its own build
> > tools (qmake, moc, uic).
>
> OCaml is not as big as TrollTech and has some annoying problems that make
> it unviable as a commercial platform in many ways but I think our company
> has shown that OCaml's commercial market is now sufficient that you can
> earn a living from it.

Which is why any sort of an OCaml startup, a company that could potentially 
provide a non-free toolkit, ide, and whatnot, would need to get some key 
customers very very soon. IIRC, the primordial trolls did get I think 10 
seats sold very soon after they were weaned off their wives (pun intended).

> To be honest, I would love to be able to buy more books on OCaml (e.g. on
> LablGTK2), more software written in OCaml and libraries for OCaml and so
> on. I believe there are now tens of thousands of prospective customers out
> there for such OCaml products.

If there was something on par with Visual Studio Standard for OCaml, even if 
the IDE was an order of magnitude simpler than that, I'd pay $1500/year for a 
single architecture without much second thoughts.

The compiler, though, would likely need to be much amended from the current 
state of affairs, as I can't see it as a viable product without offering a 
built-in C++ ABI support for ia32 at least. I.e. it must be able to interface 
not only to C libraries without writing any C code, but it must be able to 
interface directly with C++ libraries. It can, of course, use the C++ 
compiler to generate some of the needed code, but it has to be transparent. 

It also implies throwing in a C++ parser eventually, but there's no other 
way -- there's just too many good C++ libraries around to ignore them. And my 
key requirement is use of Qt -- if I can't use it, I won't buy such a 
platform, and I won't use any bindings either. To me, the whole binding thing 
is upside down: foreign-language stuff shouldn't be bent to mend with 
higher-level language, it should be the other way around: high level 
languages such as OCaml need to acquire necessary ABI support.

A good first step (good enough for me) would be for OCaml to support C++ ABI 
while not understanding any C++, i.e. only using for-the-purpose OCaml 
constructs. That way one could do the "bindings" by hand-translating some C++ 
headers to OCaml.

This could be implemented maybe in symbiosis with the trolls somehow -- after 
all they could benefit from opening up their market to functional programming 
folks.

Cheers, Kuba

RE: [Caml-list] Re: The OCaml Community (aka back fromthe Developer Days)

[David Allsopp]

> It would make sense as a business venture when you'd throw in some economy
> of scale. MS can sell visual studio for peanuts, and keep that business
> unit out of the red, of course because they sell so many.
> 
> For relatively small projects like OCaml, any "pay for a feature" scheme
> would necessarily be out of reach of many customers.

Vim does this very well with "sponsor a feature"[1] - all you need is a
structured wish-list that people can mark a (financial) interest in. That
way, if you want a feature, and so do other people, then there may be enough
combined sponsorship to pay a (reasonable) amount for it. Bram only requires
enough to pay for a basic salary so he can take time off work.

While I have no idea how many people use Vim, I would imagine that it's
rather fewer than MS Visual Studio suggesting that the finance model
"works".


David

[1] http://www.vim.org/sponsor/index.php

Re: [Caml-list] Re: The OCaml Community (aka back fromthe Developer Days)

[Kuba Ober]

On Wednesday 30 January 2008, David Allsopp wrote:
> > It would make sense as a business venture when you'd throw in some
> > economy of scale. MS can sell visual studio for peanuts, and keep that
> > business unit out of the red, of course because they sell so many.
> >
> > For relatively small projects like OCaml, any "pay for a feature" scheme
> > would necessarily be out of reach of many customers.
>
> Vim does this very well with "sponsor a feature"[1] - all you need is a
> structured wish-list that people can mark a (financial) interest in. That
> way, if you want a feature, and so do other people, then there may be
> enough combined sponsorship to pay a (reasonable) amount for it. Bram only
> requires enough to pay for a basic salary so he can take time off work.
>
> While I have no idea how many people use Vim, I would imagine that it's
> rather fewer than MS Visual Studio suggesting that the finance model
> "works".

Yeah, if you have a "feature accounts" where people can pool the money, then 
of course it'd work.

My assumption was that one person pays for a single feature.

Cheers, Kuba