[Vm-dev] why are the builds cancelled

Ben Coman btc at openinworld.com
Tue Mar 20 10:45:24 UTC 2018


On 19 March 2018 at 22:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> 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.


>From the sideline peanut gallery... the "build*" folders are not so bad
since there are not so many of them, and they advertise what platforms are
supported,
but the plethora of "*src*" directories is distracting, particularly with
the explosion from sista/lowcode/32bit/64bit variants.  If they were all
organised under a folder, would you consider also naming that parent folder
"gensrc" or "src.gen" or similar to make it explicit for newcomers that
these are generated sources.  A README in that folder might describe how
the sources are generated.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180320/e42cf191/attachment-0001.html>


More information about the Vm-dev mailing list