Posts in the run up to OCaml 2014

[amirmc]

The series of Platform posts in the run up to OCaml 2014, and shortly after.
All posts will go up on the new Platform blog at https://opam.ocaml.org/blog
This comment will be updated as things change/progress.

Week 0

• OPAM 1.2 beta - 14 Aug Added OPAM 1.2 post #2

Week 1

• OPAM pinning @AltGr - 19 Aug Added first run of opam-pin blog post #11
• DevTools I (Merlin/ocp-indent) - 21 Aug Add first draft of @def-lkb's post (for 20 Aug?) #14

Week 2

• DevTools II (UTop) - 26 Aug Add @diml's post on utop (for 26 Aug) #15
• opam2web @dsheets - 28 Aug
• OPAM Pull Request workflow @samoht and @AltGr - 29 Aug?

Week 3

• Overview/Recap - @amirmc @avsm - 1 Sep Add Platform overview post (for 29 Aug) #9
• Assemblage by @samoht - ? (draft in DO NOT MERGE: Initial draft of the assemblage post (25 Aug) #16)

Others

• OPAM-doc @lpw25 - ?
• Binary distribution via 0Install - @talex5
• Testing - Part 1 (OCamlot) - 28 Aug
• Testing - Part 2 (Travis/Flag) @avsm - 28 Aug
• Ctypes
• Jenga
• IOCaml

[talex5]

For the 0install post, it would be nice to show getting OPAM via 0install. Is it possible to get a DNS entry (e.g. tools.ocaml.org) for it? Then I could rename http://test.roscidus.com/opam.xml to http://tools.ocaml.org/opam.xml (and also update it to 1.2).

[avsm]

@talex5 yes: where would you like the DNS entry pointed? Is static HTML sufficient? If so, it could also be served by opam.ocaml.org (and benefit from the HTTPS certificate that already exists for that subdomain).

[talex5]

Anything with a static HTTP server will do (blobs, opam, etc). HTTPS isn't critical (everything's already gpg-signed), but does help slightly against replay attacks on first use.

[avsm]

Putting it on opam.ocaml.org seems the most sensible. @dsheets @AltGr -- what's the procedure for adding static content to opam.ocaml.org? I also need to add graphics for the blog posts, so @talex5 and I could both use this.

[AltGr]

@avsm: see ac2bceb

If you have <blog>.md, put the file in eg. <blog>/image.png and simply link to image.png.

Alternatively, you can also link to files from the root of the blog (images/foo.png and link to images/foo.png, still relative).
Resources are resolved and copied by opam2web, so you'll get warnings if they aren't found.

[amirmc]

Resources are resolved and copied by opam2web, so you'll get warnings if they aren't found.

Is there a way for users to build/view locally (and catch warnings/errors) before a push?

[AltGr]

Here is what I do:

• git clone [email protected]:ocaml/opam2web
• edit the test-prepare target of the Makefile to have my blog dir contents copied to content/blog (instead of git clone [email protected]:amirmc/platform git-blog -b overview --depth 1 && cp -r git-blog/blog/* content/blog/)
• run make test

Yes, there could probably be a more friendly way.

[AltGr]

Note also that markdown doesn't really have a notion of error, so markdown errors may just lead to unwanted display.

[amirmc]

I've adjusted the dates of the posts to reflect how things currently stand. We need to reconcile some of the posts for next week (I still have a question about Test - Will raise by email).

[talex5]

@avsm, @AltGr: for 0install, it might be better not to put binary archives under Git. Is there some plain server (like blobs.openmirage.org) we could make tools.ocaml.org point to?

It is possible to keep the generated XML files on e.g. github but I prefer to keep only the unsigned source XML there (because you don't want to encourage people to try and edit the signed versions). I still usually use Git to sync the signed versions to the server, but I push directly and don't expose the repository anywhere else.

[avsm]

I believe there's an ocaml.org-media repo (http://github.com/ocaml/ocaml.org-media) that we could use for this purpose. We could open up a private repository for signing keys, which could be useful for mainline downloads as well.

On 26 Aug 2014, at 11:35, Thomas Leonard [email protected] wrote:

@avsm, @AltGr: for 0install, it might be better not to put binary archives under Git. Is there some plain server (like blobs.openmirage.org) we could make tools.ocaml.org point to?

It is possible to keep the generated XML files on e.g. github but I prefer to keep only the unsigned source XML there (because you don't want to encourage people to try and edit the signed versions). I still usually use Git to sync the signed versions to the server, but I push directly and don't expose the repository anywhere else.

—
Reply to this email directly or view it on GitHub.

[talex5]

avsm: Looks like the main thing is to set up a CNAME entry:

tools.ocaml.org -> CNAME ocamllabs.github.io

(from https://help.github.com/articles/tips-for-configuring-a-cname-record-with-your-dns-provider)

Then I can create a repository using GitHub pages to publish the XML. Ideally, this should be private, because noone should see it except the repository daemon. Everyone else can interact with it through a separate Git repository with the unsigned source files.

[avsm]

Why ocamllabs.github.io? I don't believe that ocaml.github.io is currently being used, so we could map it there.

On 26 Aug 2014, at 16:24, Thomas Leonard [email protected] wrote:

avsm: Looks like the main thing is to set up a CNAME entry:

tools.ocaml.org -> CNAME ocamllabs.github.io

(from https://help.github.com/articles/tips-for-configuring-a-cname-record-with-your-dns-provider)

Then I can create a repository using GitHub pages to publish the XML. Ideally, this should be private, because noone should see it except the repository daemon. Everyone else can interact with it through a separate Git repository with the unsigned source files.

—
Reply to this email directly or view it on GitHub.

[talex5]

Either is fine for me. ocamllabs just seemed the more private option.

[amirmc]

Is this a long-term thing or just for for the short term?

If it's meant to be maintained, then the OCaml GitHub account makes sense, otherwise I'd opt for the OCaml Labs account. In addition, if the intent is to keep something private (or not have it publicly visible), then my preference is not to use the OCaml GitHub account. I think we should default to 'open' on that account wherever possible (apart from the handful of repos for admin/scripts etc — this may well be one of those but I don't know, hence the question).

[talex5]

Here's how it works:

1. There is a public Git repository containing the (unsigned) XML package metadata files. Contributors can make pull requests against this to fix problems.
2. The 0repo software, which holds the repository's private key, signs these files and pushes the signed XML to the public web server. In this case, the web server is GitHub Pages, and therefore these signed files also live in a Git repository. But this is an implementation detail. No-one should push anything to this repository except the repository software, because otherwise the signature will be invalid and it won't work. I therefore suggest making this one private.

[avsm]

But there's no actual private information in the signed repository, is there? We could just restrict push rights to the signed repository from a single mechanical account (such as the bactrian bot) which runs 0repo.

On 26 Aug 2014, at 17:07, Thomas Leonard [email protected] wrote:

Here's how it works:

There is a public Git repository containing the (unsigned) XML package metadata files. Contributors can make pull requests against this to fix problems.

The 0repo software, which holds the repository's private key, signs these files and pushes the signed XML to the public web server. In this case, the web server is GitHub Pages, and therefore these signed files also live in a Git repository. But this is an implementation detail. No-one should push anything to this repository except the repository software, because otherwise the signature will be invalid and it won't work. I therefore suggest making this one private.

—
Reply to this email directly or view it on GitHub.

[talex5]

@avsm: Yes, the only problem is confusion from having two almost identical repositories.

[avsm]

Understood -- let's aim to keep everything public but explain the workflow through README files or similar. This way, other people can replicate things with minimal confusion. The only private bit would be setting up 0repo and the signing key VM.

On 26 Aug 2014, at 17:15, Thomas Leonard [email protected] wrote:

@avsm: Yes, the only problem is confusion from having two almost identical repositories.

—
Reply to this email directly or view it on GitHub.

[talex5]

OK. Let me know when the DNS entry is added and I'll create a project for the pages and push the OPAM XML there.

[amirmc]

I concur with @avsm — Clearly explaining things via (cross-referenced) README's as well as restricting push access and issues seems like a good approach (and would also help others understand how it works). Thanks for clarifying!

[XVilka]

Maybe it worth to close this issue? It's 6 years old already and now irrelevant.