<div dir="ltr">Got it. Makes sense.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 10:47 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5">On 17 Mar 2014, at 14:19, Ashish Agarwal <<a href="mailto:agarwal1975@gmail.com" target="_blank">agarwal1975@gmail.com</a>> wrote:<br>

<div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 17, 2014 at 7:49 AM, David Sheets <span dir="ltr"><<a href="mailto:sheets@alum.mit.edu" target="_blank">sheets@alum.mit.edu</a>></span> wrote:<br>



<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Specifically, I'd like to see:<br>
<br>
1. Generated assets and build logs publicly accessible<br>
2. Build environment specification (e.g. "this stock Ubuntu image").<br>
3. History<br></blockquote><div><br></div><div>All of these could be obtained with a single server. Can you explain the benefits of splitting into a build server and static server. I'm just wondering why the extra work would be worth it.</div>



</div></div></div></blockquote><br></div></div></div><div>Because the set of people that need to build <a href="http://ocaml.org" target="_blank">ocaml.org</a> is higher than the set of deployment services we need to support.  Separating them would let us triage <a href="http://ocaml.org" target="_blank">ocaml.org</a> build failures (e.g. the obscure awk issue, or the sorts of problem that Michel or Jacques had as first time contributors), from errors in the deployment system (due to some Git infrastructure or whatever going down).</div>

<div><br></div><div>We currently implicitly support quite a few build environments (e.g. MacOS X in addition to Ubuntu), so gradually adding more CI to ensure all this stays working means less work for us in the long term.  Note that this isn't specifically an <a href="http://ocaml.org" target="_blank">ocaml.org</a> issue -- any such CI could also help OPAM package testing expand out beyond Ubuntu x86_64.</div>

<span class="HOEnZb"><font color="#888888"><div><br></div><div>-anil</div><div><br></div><br></font></span></div></blockquote></div><br></div>