<div dir="ltr">Hi Nicolas,<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 2, 2018 at 6:21 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</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"><div><div><div>Hi Fabio,<br></div>I have already edited the build stages of .tavis.yml<br></div><div>I'll publish this evening.<br></div>Maybe you will want to review?<br></div></div></blockquote><div><br></div><div>Sure, feel free to send me a PR :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>Doesn't macos build start in parallelel of inux ones?<br></div></blockquote><div><br></div><div>"Stages group jobs that run in parallel, while their stages run sequentially" [1].</div><div><br></div><div>[1] <a href="https://docs.travis-ci.com/user/build-stages/#What-are-Build-Stages%3F">https://docs.travis-ci.com/user/build-stages/#What-are-Build-Stages%3F</a></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-02 18:05 GMT+02:00 Fabio Niephaus <span dir="ltr"><<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div class="m_8939253608841844992m_3788596160940475729inboxEmptyGmelius"></div>Hi all,<div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 2, 2018 at 3:36 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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"><div>Agree,<br>you see, now it's win32 pharo.cog.spur.lowcode which triggers the gcc error<br><a href="https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1209" target="_blank">https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1209</a><br><br></div>It's like I will need the whole day with error/retry to make some green status back (or it's presomptuous).<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-02 15:29 GMT+02:00 Alistair Grant <span dir="ltr"><<a href="mailto:akgrant0710@gmail.com" target="_blank">akgrant0710@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Nicolas,<br>
<br>
Good idea.  If the build order can't be controlled...  I thought<br>
newspeak builds had been tagged so that they didn't cause the whole<br>
job to fail.  Maybe sista, lowcode and v3 builds could be marked the<br>
same?<br></blockquote></div></div></blockquote><div><br></div><div>At the moment, no builds are allowed to fail. But I'd agree that it make sense to flag experimental builds as such.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Alistair<br>
<br>
<br>
On 2 April 2018 at 15:25, Nicolas Cellier<br>
<div class="m_8939253608841844992m_3788596160940475729m_-6219960901950689237HOEnZb"><div class="m_8939253608841844992m_3788596160940475729m_-6219960901950689237h5"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> there are lot of jobs at each opensmalltalk-vm commit like<br>
> <a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361159455" rel="noreferrer" target="_blank">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361159455</a><br>
><br>
> some of these jobs are of vital importance beacuse candidates for production, some have less because rather experimental (sista lowcode) or backward compatibility (v3).</div></div></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8939253608841844992m_3788596160940475729m_-6219960901950689237HOEnZb"><div class="m_8939253608841844992m_3788596160940475729m_-6219960901950689237h5">
><br>
> If ever it's technically possible, which I didn't check, could we agree at least on the order of build stages so that we build candidates for production first and at least know if commits have an impact on these?<br>
> Currently, a single failure of experimental brand will cut the whole feedback.<br></div></div></blockquote></div></div></blockquote><div><br></div><div>We can, of course, re-organize build stages at any time. When I introduced build stages, I just wanted to have Linux builds first because Travis' macOS environments are slower (they still are, but Travis has significantly improved the situation in the meantime).</div><div>It makes sense to split builds into two the groups, stable and experimental. However, I'm not sure if we want to keep grouping by architecture at the same time because then we'd have 8 instead of 4 build stages. Maybe we just need to split the Linux and macOS build stages into Linux/macOS x Stable/Experimental and leave everything else as is?</div><div><br></div><div>Fabio</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8939253608841844992m_3788596160940475729m_-6219960901950689237HOEnZb"><div class="m_8939253608841844992m_3788596160940475729m_-6219960901950689237h5">
><br>
> It's more a temporary workaround than a long term solution, but let's make small steps, or we'll never see any progress.<br>
><br>
> Nicolas<br>
><br>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div>
<br></blockquote></div><br></div>
</blockquote></div></div>