[Caml-list] Moving ocaml to github (as well)

[Caml-list] Moving ocaml to github (as well)

[Yotam Barnoy]

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

Following on the news that camlp4 has been moved to github, I would like to
see ocaml moved to github as well (the main repository, that is -- not a
mirror):

a. The ocaml code seems under-documented, with some files still having
French documentation. I have a feeling folks on this list could do a great
job adding thorough documentation to the code if a push was made to do
that. If people could add some documentation and then make a pull request
for their documented files, we'd soon have much better documentation.
b. Better documentation would lead to more people hacking the code, which
could help accelerate ocaml development. For example, it appears that one
sorely needed feature is proper backend multiplexing. The llvm backend that
was developed a couple of years back was forked by some people to develop
heavy features, and now all of those repositories are experiencing bit-rot.
The llvm backend could instead be an optional part of the official
distribution.

Thoughts on this, anyone?

-Yotam

[-- Attachment #2: Type: text/html, Size: 1124 bytes --]

Re: [Caml-list] Moving ocaml to github (as well)

[Gabriel Scherer]

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

I think "which control version software to use" should be strictly the
choice of the developers. I've talked repeatedly with some of the major
OCaml developers about that, and my impression is that, so far, they are
happy to use SVN and see no major reason to change. I respect this choice
and don't believe we should put any pressure on their choice of everyday
tools.

I hear the argument that putting a project on github automagically
increases the amount of external contributions. This might be true, but has
yet to be demonstrated. The major entry-point for OCaml development
discussion (besides this list) is the bugtracker:
  http://caml.inria.fr/mantis/
I believe it is rather clear and easy-to-use (not as powerful as bugzilla,
but not as scary either). If you think more visible documentation of where
to go and how to contribute is needed, I'm ready to help make that happen
(for example a page on ocaml.org). On mantis we accept bugreport, which
sometimes turn into development discussion, frown upon feature requests,
and welcome patches, either uploaded as a diff, or as a link to
whatever-web-mirror-for-wichever-dcvs-you-like ( for example feel free to
fork the de-facto-official github mirror, https://github.com/ocaml/ocaml/ ,
and send a link to a commit there ).

My understanding of the "if we did X (which requires some not-fascinating
work), we would have more contributions" kind of suggestions is that there
are often cheap to propose and of doubtful effectfulness (some have been
tried in the past, with not-always-convincing results). Some things have
been done which are really nice, such as the "compiler hacking sessions"
organized in the Cambridge area by Jeremy Yallop and Leo White at
OCamllabs, and I hope we have even more of that in the future.

> The ocaml code seems under-documented, with some files still having
French documentation.
> I have a feeling folks on this list could do a great job adding thorough
documentation to the code
> if a push was made to do that.

Push ! Push ! This is a push !

I agree that the compiler code could be better commented, and have asked
and obtained agreement to encourage and review patches commenting the code.
Please send anything you've got in that direction, and tell the folks on
this list to do the same.

> For example, it appears that one sorely needed feature is proper backend
multiplexing.

Well, I would be happy to help discuss and review patches in that
direction. OCaml developers tend to be conservative in things they accept
upstream (anyone would be after 20 years of continuous development of the
same thing, with mistakes of the past bugging you endlessly), but there are
a few notable "external" contributions at each release, do not hesitate to
provide one of them.

I made a talk at an early OCaml User Paris Meeting about (my perception of)
the distribution development, which may be of interest:

http://gallium.inria.fr/~scherer/drafts/ocaml_paris_meetup_may_2013/draft.html


On Fri, Dec 20, 2013 at 8:05 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:

> Following on the news that camlp4 has been moved to github, I would like
> to see ocaml moved to github as well (the main repository, that is -- not a
> mirror):
>
> a. The ocaml code seems under-documented, with some files still having
> French documentation. I have a feeling folks on this list could do a great
> job adding thorough documentation to the code if a push was made to do
> that. If people could add some documentation and then make a pull request
> for their documented files, we'd soon have much better documentation.
> b. Better documentation would lead to more people hacking the code, which
> could help accelerate ocaml development. For example, it appears that one
> sorely needed feature is proper backend multiplexing. The llvm backend that
> was developed a couple of years back was forked by some people to develop
> heavy features, and now all of those repositories are experiencing bit-rot.
> The llvm backend could instead be an optional part of the official
> distribution.
>
> Thoughts on this, anyone?
>
> -Yotam
>

[-- Attachment #2: Type: text/html, Size: 5184 bytes --]

Re: [Caml-list] Moving ocaml to github (as well)

[Richard W.M. Jones]

On Sat, Dec 21, 2013 at 11:00:14AM +0100, Gabriel Scherer wrote:
> I think "which control version software to use" should be strictly the
> choice of the developers. I've talked repeatedly with some of the major
> OCaml developers about that, and my impression is that, so far, they are
> happy to use SVN and see no major reason to change. I respect this choice
> and don't believe we should put any pressure on their choice of everyday
> tools.

git is so superior to svn in every respect that I wish the OCaml
developers would use it.  But as you say it is their choice, and we
have git mirrors.

> I hear the argument that putting a project on github automagically
> increases the amount of external contributions. This might be true, but has
> yet to be demonstrated.

I can add some (negative) anec-data:

(1) Putting a project on github increases the number of people
submitting bug reports and pull requests using github's proprietary
interface.  This is annoying because you need some way to tell them
not to do this, and to deal with people who do it anyway.  (libguestfs
-- hosted on github -- has an all-caps notice on the front page:
http://github.com/libguestfs/libguestfs)

(2) It's easy to run your own git repository with a web interface.
There is nothing magical that github provides here except free
bandwidth and someone who looks after security errata.

> The major entry-point for OCaml development
> discussion (besides this list) is the bugtracker:
>   http://caml.inria.fr/mantis/

Having said that, I truly hate mantis with a passion ...

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Moving ocaml to github (as well)

[Richard W.M. Jones]

And:

(3) To all intents and purposes, OCaml is already on github, ie:
https://github.com/ocaml/ocaml .  So the massive influx of developers
should have already happened.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Moving ocaml to github (as well)

[Markus Mottl]

The reason why the "massive influx of developers" hasn't happened may
be that making small contributions is perceived as more costly when
the authoritative repository is not on Github.  Most contributors only
make small contributions.  If you make large and/or frequent
contributions, the cost may seem negligible as you adjust to the
"indirect" workflow.  At least what concerns me, I might have
submitted a tiny patch here or there, but felt that the development
model is not open enough for small or less important contributions so
I didn't bother.  That's why I'd also love to see the OCaml team go
"distributed", preferably either Git (github) or Mercurial
(Bitbucket).

Regards,
Markus

On Sun, Dec 22, 2013 at 9:07 AM, Richard W.M. Jones <rich@annexia.org> wrote:
> And:
>
> (3) To all intents and purposes, OCaml is already on github, ie:
> https://github.com/ocaml/ocaml .  So the massive influx of developers
> should have already happened.
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs



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

Re: [Caml-list] Moving ocaml to github (as well)

[Gabriel Scherer]

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

I understand that this is a matter of "perception" that relies on
subjective aspects, but I would like to point out that, objectively, there
is not much difference between a github-style workflow and what currently
happens for "small contribution" (one-shot patches).

Probably the most common workflow on github is approximately as follows:
  (1) clone the github repository
  (2) get it to compile by following whatever instruction (OCaml has an
INSTALL file)
  (3) do your change, compile again and test
  (4) fork the github repository (some peopele do that at point (1)), push
your changes, submit a pull request

By comparison, my current OCaml workflow is as follows:
  (1) clone the github repository
  (2) identical
  (3) identical
  (4) use "git format-patch HEAD~1" to get a patch, submit it on mantis
(New Issue, upload a file)
       (recently some people just provide a link to the commit on their
github or wherever and it works just as well)

I understand that github provides an homogeneous experience so that users
don't have to wonder about what the workflow is, and that OCaml users may
need more explicit information about how to contribute (we can work on
that). I'm a bit surprised that an expert user that is a long-time
contributor on the bugtracker, such as Markus, would perceive a difference
in difficulty/welcome-ness here.



On Sun, Dec 22, 2013 at 4:53 PM, Markus Mottl <markus.mottl@gmail.com>wrote:

> The reason why the "massive influx of developers" hasn't happened may
> be that making small contributions is perceived as more costly when
> the authoritative repository is not on Github.  Most contributors only
> make small contributions.  If you make large and/or frequent
> contributions, the cost may seem negligible as you adjust to the
> "indirect" workflow.  At least what concerns me, I might have
> submitted a tiny patch here or there, but felt that the development
> model is not open enough for small or less important contributions so
> I didn't bother.  That's why I'd also love to see the OCaml team go
> "distributed", preferably either Git (github) or Mercurial
> (Bitbucket).
>
> Regards,
> Markus
>
> On Sun, Dec 22, 2013 at 9:07 AM, Richard W.M. Jones <rich@annexia.org>
> wrote:
> > And:
> >
> > (3) To all intents and purposes, OCaml is already on github, ie:
> > https://github.com/ocaml/ocaml .  So the massive influx of developers
> > should have already happened.
> >
> > Rich.
> >
> > --
> > Richard Jones
> > Red Hat
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
>
> --
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>

[-- Attachment #2: Type: text/html, Size: 4288 bytes --]

Re: [Caml-list] Moving ocaml to github (as well)

[Markus Mottl]

On Sun, Dec 22, 2013 at 11:41 AM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> I understand that github provides an homogeneous experience so that users
> don't have to wonder about what the workflow is, and that OCaml users may
> need more explicit information about how to contribute (we can work on
> that). I'm a bit surprised that an expert user that is a long-time
> contributor on the bugtracker, such as Markus, would perceive a difference
> in difficulty/welcome-ness here.

I think people generally underestimate by how much lower contribution
hurdles or "better user experience" can improve adoption rates.  The
OPAM vs Godi story should act as a reminder for that.  It's not that
Godi couldn't do what OPAM does, in fact, I think it could do pretty
much all of what users and developers needed.  It's just that it
required developers and users to jump through a few more hoops to
achieve the intended results, enough to prevent it from gaining such
quick and wide adoption.

Some of the issues may be more perceived than real.  E.g. a
contributor might fear that their patch is more likely to be ignored
in a bug tracker, maybe because it clashes with newer changes due to
the lack of revision control.  But at the end of the day the only
thing that matters is whether a developer is willing to make a
contribution.  Your milage on larger, more complex projects may vary,
but when I translated/switched my projects from CVS to Mercurial on
Bitbucket (Github surely would be similar), the effort was so
laughably small, literally a few minutes per project, I'd find it hard
to believe that workarounds or improved documentation for better
interaction through SVN could possibly be worth it.

Regards,
Markus

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

Re: [Caml-list] Moving ocaml to github (as well)

[Martin Jambon]

I would like to point out that Github is as much about people as it is 
about code. Much of the communication happens there and discussions are 
usually linked to a particular context (code diffs) unlike mailing-lists.

Github also makes it easy to judge the health of a project in a few 
clicks. This matters for product adoption because the following 
questions will arise:

1. Is the project popular enough so I won't have to fix any bug myself?
(God I hope I'll stay among the 99% passive users)

2. If a few problems are expected, will I be able to fix them myself?
(nothing like a good hack once in a while)

3. If bigger problems happen, can I afford to become a contributor?
(you guys better be really awesome)


Martin

--
Feel free to downvote this message.


On 12/22/2013 08:41 AM, Gabriel Scherer wrote:
> I understand that this is a matter of "perception" that relies on
> subjective aspects, but I would like to point out that, objectively,
> there is not much difference between a github-style workflow and what
> currently happens for "small contribution" (one-shot patches).
>
> Probably the most common workflow on github is approximately as follows:
>    (1) clone the github repository
>    (2) get it to compile by following whatever instruction (OCaml has an
> INSTALL file)
>    (3) do your change, compile again and test
>    (4) fork the github repository (some peopele do that at point (1)),
> push your changes, submit a pull request
>
> By comparison, my current OCaml workflow is as follows:
>    (1) clone the github repository
>    (2) identical
>    (3) identical
>    (4) use "git format-patch HEAD~1" to get a patch, submit it on mantis
> (New Issue, upload a file)
>         (recently some people just provide a link to the commit on their
> github or wherever and it works just as well)
>
> I understand that github provides an homogeneous experience so that
> users don't have to wonder about what the workflow is, and that OCaml
> users may need more explicit information about how to contribute (we can
> work on that). I'm a bit surprised that an expert user that is a
> long-time contributor on the bugtracker, such as Markus, would perceive
> a difference in difficulty/welcome-ness here.
>
>
>
> On Sun, Dec 22, 2013 at 4:53 PM, Markus Mottl <markus.mottl@gmail.com
> <mailto:markus.mottl@gmail.com>> wrote:
>
>     The reason why the "massive influx of developers" hasn't happened may
>     be that making small contributions is perceived as more costly when
>     the authoritative repository is not on Github.  Most contributors only
>     make small contributions.  If you make large and/or frequent
>     contributions, the cost may seem negligible as you adjust to the
>     "indirect" workflow.  At least what concerns me, I might have
>     submitted a tiny patch here or there, but felt that the development
>     model is not open enough for small or less important contributions so
>     I didn't bother.  That's why I'd also love to see the OCaml team go
>     "distributed", preferably either Git (github) or Mercurial
>     (Bitbucket).
>
>     Regards,
>     Markus
>
>     On Sun, Dec 22, 2013 at 9:07 AM, Richard W.M. Jones
>     <rich@annexia.org <mailto:rich@annexia.org>> wrote:
>      > And:
>      >
>      > (3) To all intents and purposes, OCaml is already on github, ie:
>      > https://github.com/ocaml/ocaml .  So the massive influx of developers
>      > should have already happened.
>      >
>      > Rich.
>      >
>      > --
>      > Richard Jones
>      > Red Hat
>      >
>     > --
>     > Caml-list mailing list.  Subscription management and archives:
>     >https://sympa.inria.fr/sympa/arc/caml-list
>     > Beginner's list:http://groups.yahoo.com/group/ocaml_beginners
>     > Bug reports:http://caml.inria.fr/bin/caml-bugs
>
>
>
>     --
>     Markus Mottl http://www.ocaml.info markus.mottl@gmail.com
>     <mailto:markus.mottl@gmail.com>
>
>

Re: [Caml-list] Moving ocaml to github (as well)

[Daniel Bünzli]

Le dimanche, 22 décembre 2013 à 15:03, Richard W.M. Jones a écrit :

> (2) It's easy to run your own git repository with a web interface.
> There is nothing magical that github provides here except free
> bandwidth and someone who looks after security errata.

True. I do that for my packages on erratique.ch using github only as a mirror.  

But while I strive to make my development workflow as independent as possible from github, there's something hosting your own git repository won't solve which is the collaboration aspects that github solves pretty well without too much bureaucracy, across projects, using a good balance of email/web interface. The issue tracker is actually the only one I have ever used that is decent and watching/unwatching projects is a breeze -- it's not magic, but it's very useful. I would welcome a distributed solution to these problems but for the time being it doesn't exist.  

As for github's fork/pull request model, it seems completely broken to me but suffixing the url of a pull request with `.patch` gives you a file that you can apply with `git am`, so I now let people interact with me that way if it's easier for them.  

> Having said that, I truly hate mantis with a passion ...
Same here.  

Daniel

Re: [Caml-list] Moving ocaml to github (as well)

[Ashish Agarwal]

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

On Sun, Dec 22, 2013 at 9:03 AM, Richard W.M. Jones <rich@annexia.org>wrote:

(1) Putting a project on github increases the number of people
> submitting bug reports and pull requests using github's proprietary
> interface.  This is annoying because you need some way to tell them
> not to do this, and to deal with people who do it anyway.  (libguestfs
> -- hosted on github -- has an all-caps notice on the front page:
> http://github.com/libguestfs/libguestfs)
>

Click the settings icon at the middle right (for the individual repo, not
the general account settings at the top right). There, you can disable the
Issues and Wiki features. I don't know any way to prevent submission of
pull requests. (I don't agree that these features should be avoided. I
think GitHub is by far the best development tool set currently available.)

[-- Attachment #2: Type: text/html, Size: 1282 bytes --]

Re: [Caml-list] Moving ocaml to github (as well)

[Yotam Barnoy]

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

Thank you for the very informative presentation, Gabriel.

Markus sums up a lot of my thoughts on the subject. One can point to so
many examples of competitors that gained momentum vs ones that lost it:
Amazon vs every other retailer, Apple vs Microsoft, Facebook vs Myspace
etc. What gets neglected is the little decisions along the way that helped
gain momentum. Those little things cause other little consequences, many of
them unpredictable. My research group used to use Assembla, which is a
decent hosting site, but one of our members forced us to switch to github,
and we haven't looked back: github has so many small features you get used
to, starting with its highly intelligent browsing engine compared to every
other solution, that other hosting sites can't compete. The combination of
git + github's feature-set makes github unbeatable.

As another example of momentum, my research group has already moved on to
Haskell, mostly for its parallelization abilities. I actually get laughed
at when I mention that I still use ocaml for my personal projects, though
it's still my personal preference.

As further anecdotal evidence, I would never have perused ocaml's source
code had I not searched for it on github. Of course, once I found out it
was a mirror of an svn, I was somewhat disappointed and lost any intention
of directly contributing (at the time). That's just human nature --
'everybody' is on github now, and for good reason, and
researchers/programmers want to streamline their toolsets and processes
just as much as the next person.

In order for ocaml to survive and thrive, it needs users. Many, many users.
Gabriel's presentation mentions that decisions made about ocaml's evolution
will still be there in 2025. They probably will, but ocaml may just be a
small personal project at that point -- much like the countless personal
languages I see around my department. Languages need to be marketed, and
they need to go viral to succeed. (The best salesmen I know for ocaml are
Anil and Yaron). Moving fully to github is not a huge step in that
direction, but I believe it's a step nonetheless.

-Yotam


On Sun, Dec 22, 2013 at 5:55 PM, Ashish Agarwal <agarwal1975@gmail.com>wrote:

> On Sun, Dec 22, 2013 at 9:03 AM, Richard W.M. Jones <rich@annexia.org>wrote:
>
> (1) Putting a project on github increases the number of people
>> submitting bug reports and pull requests using github's proprietary
>> interface.  This is annoying because you need some way to tell them
>> not to do this, and to deal with people who do it anyway.  (libguestfs
>> -- hosted on github -- has an all-caps notice on the front page:
>> http://github.com/libguestfs/libguestfs)
>>
>
> Click the settings icon at the middle right (for the individual repo, not
> the general account settings at the top right). There, you can disable the
> Issues and Wiki features. I don't know any way to prevent submission of
> pull requests. (I don't agree that these features should be avoided. I
> think GitHub is by far the best development tool set currently available.)
>
>

[-- Attachment #2: Type: text/html, Size: 3964 bytes --]