[Vm-dev] why are the builds cancelled

[Eliot Miranda]

Hi Tobias,

> On Mar 19, 2018, at 1:38 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> 
> Hi,
> 
>> On 19.03.2018, at 01:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> Hi,
>> 
>>    Travis isn't building new commits and I don't know why.  Can someone update the README.md for opensmalltalk/vm with a pointer to an overview of the Travis CI infrastructure so that someone could work out why things aren't working?
> 
> 
> Things are working ;)
> What happens is: we're using build stages to minimize load on travis and to get faster feedback.
> 
> Let's take this as an example:
>    https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/354870586
> 
> We currently have four stages:
> - Linux builds 
> - Mac builds 
> - Stack builds 
> - Linux32armv6 builds
> 
> Each stage will only start iff the previous stage completed successfully, essentially saying "if those builds did not run, don't even bother looking at me"
> 
> So, since the Linux builds did not complete all (in fact, only one did), all subsequent stages are ignored.
> 
> This actually ensures that we get swifter response, as later builds are more likely to run.
> 
> Does that help?

Yes, but... :-). Forgive the "but".  The issue is I had to ask and couldn't work it out myself.  What would really help would be a paragraph in README.md that gives an overview of the build slave and of bintray.  Something like

"The various VMs are built and tested using Travis CI at ...  Successful builds are uploaded to bintray for download at... The tests determining a "successful build" are...

I wrote the initial draft of README.md and now I find it too chatty and not well laid out.  Much of my content could be relegated to a "VM Source Generation" subsection and the intro could be firmed up and aimed at the general reader.  What I'm saying is that if someone does edit README.md to include pointers to the CI build pipeline, they shouldn't be afraid of improving the overall structure of README.md.

On a related note, README.md is buried in a long list of top level directories.  Personally, keeping the directory hierarchy relatively flat helps me when fixing things.  Often one is in a build directory and it's nice to avoid an additional ../.  And of course changing the layout means fixing not just makefiles, but the autoconf stuff in platforms/unix/conf and Travis stuff and the VMMaker source and...  and making this change just to make README.md more prominent seems like putting the cart before the horse, the tail wagging the dog, etc.  so one simple layout change would be to move all the build.*, *src,  platforms, processors, .third-party stuff down into a directory (software?).  Or do people feel strongly that it should be reorganised, e.g. as

       src/
           plugins/
           spur/
           spur64/
           v3/
       build/
           linux32ARMv6
           ...

I'm for as little busy work as possible.  But recognize that README.md is an important portal on the project, so it needs to be prominent and well laid out, a principle reader being the first-time reader trying to work out how to get at builds or to start building their own.

> 
> Best regards
>    -Tobias
> 
> 
> 
>> 
>> _,,,^..^,,,_
>> best, Eliot
>