[Vm-dev] why are the builds cancelled

[Eliot Miranda]

Hi Ben,  Hi All,

On Tue, Mar 20, 2018 at 3:45 AM, Ben Coman <btc at openinworld.com> wrote:

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

I like this idea.  So we would have the src tree as described above.  So if
we change this what is impacted?  here's a partial list.  Can people please
add to the list?

all makefiles under build, (and those generated by platforms/unix/config
scripts)
some of the platforms/unix/conf generation stuff, in particular
platforms/unix/config/configure.ac
README.md
VMMaker generation specifications in VMMaker.oscog

Others?  (checkout scripts for CI that check-out a subset of sources, etc?)

cheers -ben
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180320/9a512f93/attachment.html>