+ infrastructure sorry<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 8, 2016, 9:48 AM Sylvain Le Gall <<a href="mailto:sylvain@le-gall.net">sylvain@le-gall.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg">Just to make it clear to everyone: <div class="gmail_msg">The forge will be deprecated but I haven't made an official statement about it (pending). The official recommendation will be to migrate projects to Github, but I'll keep a STATIC website of the forge -- for the project that have no plan to migrate.<div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">Le mer. 7 déc. 2016 à 17:22, Amir Chaudhry <<a href="mailto:amc79@cam.ac.uk" class="gmail_msg" target="_blank">amc79@cam.ac.uk</a>> a écrit :<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On 7 Dec 2016, at 15:28, Anil Madhavapeddy <<a href="mailto:anil@recoil.org" class="gmail_msg" target="_blank">anil@recoil.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> On 7 Dec 2016, at 15:14, Xavier Leroy <<a href="mailto:Xavier.Leroy@inria.fr" class="gmail_msg" target="_blank">Xavier.Leroy@inria.fr</a>> wrote:<br class="gmail_msg">
>> On 12/07/2016 03:43 PM, Anil Madhavapeddy wrote:<br class="gmail_msg">
>>> On 7 Dec 2016, at 14:15, Xavier Leroy <<a href="mailto:Xavier.Leroy@inria.fr" class="gmail_msg" target="_blank">Xavier.Leroy@inria.fr</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>>>> So, what is the policy? how to request a new /ocaml/xxx project?<br class="gmail_msg">
>>>> who takes the decision?<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Technically speaking, you own the final say on the namespace,<br class="gmail_msg">
>>> so you make the decision in case of conflict :-)<br class="gmail_msg">
>><br class="gmail_msg">
>> Not sure! Before posting I re-read the governance document, in<br class="gmail_msg">
>> case my questions were already answered there. According to this<br class="gmail_msg">
>> document, I do own the final say on hostnames in the <a href="http://ocaml.org" rel="noreferrer" class="gmail_msg" target="_blank">ocaml.org</a> domain.<br class="gmail_msg">
>> But the Github ocaml/ organization & namespace is something different,<br class="gmail_msg">
>> not covered (yet?) in the governance document.<br class="gmail_msg">
>><br class="gmail_msg">
>> I suspect that, as one of the admins of this organization, I wield<br class="gmail_msg">
>> considerable technical power there as well. But I definitely don't<br class="gmail_msg">
>> want to misuse or abuse it, hence my questions re: policy and<br class="gmail_msg">
>> procedure.<br class="gmail_msg">
><br class="gmail_msg">
> Dear Xavier,<br class="gmail_msg">
><br class="gmail_msg">
> Good point -- I will put GitHub on the list of things to add to the<br class="gmail_msg">
> governance doc. We also need somewhere to stash private keys<br class="gmail_msg">
> for infrastructure machines as well, so there are a few other items<br class="gmail_msg">
> of that nature that warrant a refresh.<br class="gmail_msg">
<br class="gmail_msg">
The governance doc was specifically written for the <a href="http://ocaml.org" rel="noreferrer" class="gmail_msg" target="_blank">ocaml.org</a> domain.<br class="gmail_msg">
Of course, it can be modified and extended to cover other things but the management and policy around code repos was not part of the original scope.<br class="gmail_msg">
<br class="gmail_msg">
I mention this in case anyone think it’ll be a trivial thing to add :)<br class="gmail_msg">
<br class="gmail_msg">
>>> So far, the policy has been any project that is reasonably needed<br class="gmail_msg">
>>> for the operation of the <a href="http://ocaml.org" rel="noreferrer" class="gmail_msg" target="_blank">ocaml.org</a> infrastructure. Some of them are<br class="gmail_msg">
>>> obvious: [...]<br class="gmail_msg">
>>> When we first created the GitHub org, it was also the home for<br class="gmail_msg">
>>> some popular community libraries: [...]<br class="gmail_msg">
>>> More recently of course, the OCaml compiler and its tools have<br class="gmail_msg">
>>> also started moving over: [...]<br class="gmail_msg">
>>><br class="gmail_msg">
>>> So now that we have been using GitHub for a few years, there<br class="gmail_msg">
>>> is quite an array of libraries on the ocaml/ organisation, and<br class="gmail_msg">
>>> possibly time to do a garbage collection and disaggregate the<br class="gmail_msg">
>>> namespace if necessary.<br class="gmail_msg">
>><br class="gmail_msg">
>> As far as the number of projects in ocaml/ remains tractable<br class="gmail_msg">
>> (e.g. tens, not hundreds), it's OK to host all of them and not<br class="gmail_msg">
>> worry too much about reorganization. My (hypothetical) concern is:<br class="gmail_msg">
>> what happens do if, say, all projects from <a href="http://forge.ocamlcore.org" rel="noreferrer" class="gmail_msg" target="_blank">forge.ocamlcore.org</a> ask to<br class="gmail_msg">
>> migrate to the /ocaml/ organization on Github?<br class="gmail_msg">
><br class="gmail_msg">
> I have been wondering about this also. Perhaps we should<br class="gmail_msg">
> take the initiative and create an ocaml-forge organisation that<br class="gmail_msg">
> mirrors the existing Forge Git repositories?<br class="gmail_msg">
> We cannot do much about issues, but it's fairly straightforward to<br class="gmail_msg">
> mirror the source code. SVN will require an authoritative mirror<br class="gmail_msg">
> since the results of SVN2Git aren't always reproducible.<br class="gmail_msg">
<br class="gmail_msg">
IIRC Forge offers multiple features: Code, Mailing lists, and Issues.<br class="gmail_msg">
<br class="gmail_msg">
— Code —<br class="gmail_msg">
I would think that the correct analogy for this aspect of Forge would be GitHub itself. i.e. the maintainers move their repos/code to their own namespaces/orgs on GitHub.<br class="gmail_msg">
<br class="gmail_msg">
Some of those would make sense to move to /ocaml but that would involve a case-by-case discussion between the owners of /ocaml (i.e. you) and the maintainers of those codebases.<br class="gmail_msg">
<br class="gmail_msg">
Mirroring the existing Git repos into an ‘ocaml-forge’ organisation, as Anil suggests, might also be a good way to facilitate a mass migration.<br class="gmail_msg">
<br class="gmail_msg">
As a sidenote, there are benefits and trade-offs to moving projects into a GitHub organisation. For example, the owners of a GitHub organisation have push access to all the repositories within their org, which is worth bearing in mind. On the other hand, managing teams and collaborators is a little easier from within an organisation. Projects could make their own organisations if they wish — e.g. Merlin lives under an organisation rather than an individual’s account, <a href="https://github.com/the-lambda-church/merlin" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/the-lambda-church/merlin</a>.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Mass migration under an organisation is still an option for the Forge migration but:</div><div class="gmail_msg">- it will generate quite a lot of work</div><div class="gmail_msg">- lot of long discussions (some project may not want to be mass migrated to github, but would prefer GitLab or other)</div><div class="gmail_msg">- probably only 20 migrated repositories will be active afterward</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There are probably 20-ish projects really active on the Forge, on top of 318 projects. I have 6 entries for people connecting to SSH to commit things in the last 6 months (3 of them are from me). So all in all, we are talking about 4 - 5 people using the VCS on the forge (like Xavier, me and another couple of people).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Do we really want to migrate 318 projects for 20 active ones?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">My best guess would be to document how to migrate the VCS and let the few active people do it. I need to put in place a way to give the data back to people from the forge. The forge itself will be transformed into a static website at a certain point.</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
— Mailing lists —<br class="gmail_msg">
It's possible to set up mailing lists on <a href="http://lists.ocaml.org" rel="noreferrer" class="gmail_msg" target="_blank">lists.ocaml.org</a> and move archives over. This has happened before so I don’t imagine any difficulties, other than logistics.<br class="gmail_msg">
<br class="gmail_msg">
— Issues —<br class="gmail_msg">
As Anil said, I’m not sure there’s much to be done about Issue Trackers and Task lists.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Migrating issues will be a pain and was the thing that made me procrastinate over the last 6 months about the migration project. On the other hand, >45% of the opened issues are filed against OASIS project:</div><div class="gmail_msg">OASIS: 45%</div><div class="gmail_msg">Extunix: 8%</div><div class="gmail_msg">OUnit: 8%</div><div class="gmail_msg">Tuareg: 8%</div><div class="gmail_msg">yypkg: 4%</div><div class="gmail_msg">archimedes: 4%</div><div class="gmail_msg">cryptokit: 3.5%</div><div class="gmail_msg">...</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">You should not forget:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- Home pages --</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Some project actively use <a href="http://XXX.forge.ocamlcore.org" class="gmail_msg" target="_blank">XXX.forge.ocamlcore.org</a> as their homepages, we can suggest them to migrate to GH pages, but it will be pretty manual. </div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> In Merlin's case, Fred also provided the mailing list archive,<br class="gmail_msg">
> so that has been migrated to <a href="http://lists.ocaml.org" rel="noreferrer" class="gmail_msg" target="_blank">lists.ocaml.org</a> now:<br class="gmail_msg">
> <a href="https://github.com/ocaml/infrastructure/issues/5" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/ocaml/infrastructure/issues/5</a><br class="gmail_msg">
><br class="gmail_msg">
>>> It would be great to keep the [libraries formerly in the compiler<br class="gmail_msg">
>>> distribution] underneath the ocaml/ organisation. There is also<br class="gmail_msg">
>>> precedent for moving important core libraries such as Zarith into<br class="gmail_msg">
>>> ocaml/<br class="gmail_msg">
>><br class="gmail_msg">
>> Duly noted. But Nums and Zarith were two easy examples :-)<br class="gmail_msg">
>><br class="gmail_msg">
>> Concretely: I'll try to work on the otherlibs/num -> ocaml/num[s]<br class="gmail_msg">
>> migration in the coming weeks, and will ask for help if I can't<br class="gmail_msg">
>> manage. For other possible "immigrant" projects, let's give other<br class="gmail_msg">
>> people on this list time to think about it.<br class="gmail_msg">
><br class="gmail_msg">
> Makes sense. I am also CCing Sylvain onto this thread in case<br class="gmail_msg">
> he is not on the Infrastructure list.<br class="gmail_msg">
<br class="gmail_msg">
Since Sylvain is listed as Maintainer for a sub-domain he should already be on the infrastructure list :)<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I am ;-)</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Best wishes,<br class="gmail_msg">
Amir<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div></div></div></blockquote></div>