<div dir="ltr"><div><div><div><div><div><div><div><div>+1 for using generous features of github.</div><div>creating branches is a cheap action for developpers<br></div><div><br></div>I also see another problem: we use two different paths for developping the VM<br></div>- via VMMaker (slang) changes and VM simulator tests<br></div>- via code generation from VMMaker, compilation of VM, and non regression testing by passing some image SUnit test cases<br><br></div>Only the latest form is on Opensmalltalk-vm (github) right now.<br></div>This can lead to long periods without github/travis tests.<br></div>In our case see:</div><div><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/spur64src/vm/cogitX64WIN64.c">https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/spur64src/vm/cogitX64WIN64.c</a></div><div><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/spur64src/vm/gcc3x-cointerp.c">https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/spur64src/vm/gcc3x-cointerp.c</a><br></div>there's been no travis regression tests from VMMaker.oscog-eem.2262 to VMMaker.oscog-eem.2277 for the JIT<br>and from VMMaker.oscog-eem.2266 to VMMaker.oscog-eem.2277 for the interpreter...<br>That's a lot of changes at once.</div><div><br></div><div>In particular, each and every change to CCodeGeneration SHALL be tested individually on github/travis, because it is precisely what can make a difference between the VM simulator and the C code.</div><div><br></div>So having the code generated from VMMaker committed into a specific branch as already proposed might help bissecting the problems...<span class="gmail-hidden-text-expander gmail-inline"></span><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-24 7:47 GMT+01:00 Holger Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 24. Nov 2017, at 13:27, Ben Coman <<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>> wrote:<br>
><br>
<br>
Hey!<br>
<br>
<br>
><br>
> I haven't used them, but there seem a few options for issuing PRs from the command-line, which may make this more palatable.<br>
> Thus the CI should run without needing to visit github's web-UI.<br>
<br>
<br>
and one can probably use the github API to auto-merge PRs that have a successful build and come from a trusted developer. It is nice to live in a time computing time is so cheap. ;)<br>
<span class="HOEnZb"><font color="#888888"><br>
holger</font></span></blockquote></div><br></div>