<div dir="ltr"><div><div><div><div>(Forking the thread as this is not about <a href="http://ocaml.org">ocaml.org</a> domain governance, but an aspect of the <a href="http://ocaml.org">ocaml.org</a> website -- called the "WWW project" in the governance document.)<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="">> Finally, the compiler/distribution is now distributed on <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a>,</span><br><span class="">
> since <a href="http://caml.inria.fr" rel="noreferrer" target="_blank">caml.inria.fr</a> is deprecated. But is it an <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> project ?</span><br><span class=""></span></blockquote><span class="">
<br></span>> Xavier and Damien have administrative access to any <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> needed already.<br><br></div>Should we consider that updating the relevant <a href="http://ocaml.org">ocaml.org</a> pages is part of the release process?<br><br>This isn't done currently. In fact:<br>- <a href="http://ocaml.org">ocaml.org</a> has no mention of the new OCaml releases anywhere<br></div>- the Install page is out of date with respect to OCaml versions (it says `opam switch 4.02.1` instead of `opam switch 4.02.3`).<br><br></div>On the last couple releases I have helped (as part of my Changelog-patting process) Damien and Xavier come up with a short summary of the changes, to craft an announce on <a href="http://caml.inria.fr">caml.inria.fr</a>. Should we do this for <a href="http://ocaml.org">ocaml.org</a> now? <br><div><br></div><div>One subtlety is that some updates only make sense after the corresponding OPAM switch has been made available in the official repository. There is no formalized synchronization between the release announcment and a switch, but in practice a switch is released on the day of the release, and for 4.02.2 and 4.02.3 it was prepared by Damien directly (and merged in a few hours by the opam-repository maintainers).<br><br>We could send a pull request for the website at the same time as the compiler description, and wait for its integration to announce the release.<br>
<div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 5:43 PM, Anil Madhavapeddy <span dir="ltr"><<a href="mailto:anil@recoil.org" target="_blank">anil@recoil.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 14 Sep 2015, at 16:22, Fabrice Le Fessant <<a href="mailto:Fabrice.Le_fessant@inria.fr">Fabrice.Le_fessant@inria.fr</a>> wrote:<br>
><br>
> On Mon, Sep 14, 2015 at 3:23 PM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
>> Consider how many companies have come and gone in OCaml's 20 year history.<br>
>> The same individual characters still pop up with alarming regularity<br>
>> through those years, however, no matter who the paymasters are :-)<br>
><br>
> I have exactly the opposite opinion: companies have been quite<br>
> consistent in their choice of OCaml (with good reasons ;-) ), and once<br>
> they had a good part of their software in OCaml, it's hard for them to<br>
> stop supporting it. The membership of the Caml Consortium has been<br>
> also very constant over the years, increasing slowly but keeping most<br>
> former members.  When Thomas left OCamlPro, it was also the fact that<br>
> we already had started to distribute his knowledge of OPAM that<br>
> allowed us to go on in the developement without almost any disruption<br>
> (and today, we already have other developers ready to take over the<br>
> development if Louis gets bored). On the contrary, individuals are<br>
> much more versatile, they can contribute full-time to OCaml (if their<br>
> employer allows them), or only part-time (on spare time), or not at<br>
> all (if they get interested in a project that uses OCaml, but do not<br>
> contribute to it) depending on many different constraints, that<br>
> <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> should depend on.<br>
<br>
</span>My point is not that companies backing OCaml aren't valuable, but that<br>
the individuals themselves should commit to the 'board of trustees'<br>
(as Xavier put it).  For instance, my observation is that the real<br>
handoff of OPAM happened after Thomas left OCamlPro, over the course<br>
of a year.  This was primarily a 1:1 between him and Louis via the<br>
usual code mentoring, and happened as a personal undertaking.<br>
<span class=""><br>
> Anyway, I am still puzzled by this document, I would have expected a<br>
> dedicated organization (an "association" in French law) to take over<br>
> this task, as it is the case for some other open-source languages<br>
> (Python for example). What is the legal meaning of signing this<br>
> document ? In an association, the governance dictates who governs the<br>
> association, what they can do (i.e. what they are allowed to do, and<br>
> what they are not allowed to do), who votes for them, how to become a<br>
> member, etc. And if you don't follow the association rules, you are<br>
> excluded. Here, I don't see any such thing.<br>
<br>
</span>There is no legal meaning to signing this document, because nobody is<br>
signing anything.  It is, as Amir noted, a "living document" that<br>
simply documents what superstructure exists at the moment.  As Xavier<br>
notes, many of the resources currently used by <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> are owned<br>
personally by several of us, and we are keen to 1) ensure that their<br>
ownership is tracked; and 2) a path of authority exists to one person<br>
(Xavier Leroy) to facilitate any conflict resolution.<br>
<br>
There may be an OCaml Foundation in the future, but there have been<br>
no concrete movements in this direction yet beyond this effort to<br>
document what currently exists.<br>
<span class=""><br>
> Let's take some examples of things that could also be clarified: if<br>
> somebody wants a new project to become an <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> project, how long<br>
> is he supposed to wait to get a reply ? When is the "consensus phase"<br>
> supposed to end, if nobody replies with either yes or no ?  Is it yes<br>
> by default, or no by default ? What if nobody is against the project,<br>
> but still the sub-domain name is not created ? on the contrary,<br>
> suppose that there is no consensus for a project, but somebody with<br>
> admin rights decides to still create the sub-domain, is it ok ?<br>
><br>
> For me, such a document should handle all these cases, and the process<br>
> should be democratic (admin rights should be put to a vote by the<br>
> members). Which leads to having an association for that. And<br>
> associations usually welcome institutions too, not only individuals,<br>
> even if they give them different rights.<br>
<br>
</span>We will need to clarify all of these things together, moving forward.<br>
For now, the important scope from my perspective is simply to document<br>
what we have an ensure that the community knows what is available<br>
(e.g. the mailing lists), and to enable people who are interested in<br>
helping to step up.  For instance, if someone wanted to help manage the<br>
mailing list infrastructure other than me, I'd be quite happy to<br>
document it better and grant access.  The only area where I really<br>
need to keep control is the Rackspace VM infrastructure, since it<br>
puts around $25,000 a year onto my personal credit card before being<br>
reimbursed...<br>
<br>
I'm sure we will all come up with a nice democratic system in a few<br>
years when our community grows so large that we need to elect local<br>
governors of the subdomains.  For now though, this seems like a poor<br>
reason to refrain from documenting the status quo that already exists.<br>
<span class=""><br>
> Finally, the compiler/distribution is now distributed on <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a>,<br>
> since <a href="http://caml.inria.fr" rel="noreferrer" target="_blank">caml.inria.fr</a> is deprecated. But is it an <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> project ?<br>
> What rights have the core-team members over the corresponding pages ?<br>
> Shall they care about changing them in the event of the migration of<br>
> sources from SVN to GIT, or is it a task for the <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> project<br>
> itself ?<br>
<br>
</span>Xavier and Damien have administrative access to any <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> needed<br>
already.<br>
<br>
I'm also trying to understand if there's something you need that you<br>
can't currently do with the <a href="http://ocaml.org" rel="noreferrer" target="_blank">ocaml.org</a> infrastructure... happy to help<br>
as I can if so.<br>
<br>
regards,<br>
Anil<br>
<div class=""><div class="h5">_______________________________________________<br>
Infrastructure mailing list<br>
<a href="mailto:Infrastructure@lists.ocaml.org">Infrastructure@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/infrastructure" rel="noreferrer" target="_blank">http://lists.ocaml.org/listinfo/infrastructure</a><br>
</div></div></blockquote></div><br></div></div></div></div>