>> I think we need to stay with self-documenting release images.  The
>> purpose of ReleaseBuilder is to tell us how that release image was
>> built.  That's not nonsense.
>
> The Squeak user doesn't care about ReleaseBuilder. The trunk developer
> doesn't care about ReleaseBuilder. Only one person cares about
> ReleaseBuilder, and that's the release manager. And that's once per
> release cycle. It's scaffolding. It's a one-off janitorial task that,
> other than at the end of a release cycle, is deadweight in the image.
>
> I didn't say that _ReleaseBuilder_ was nonsense. I said _it being in
> the base image_ was nonsense. I mean, come on, didn't your builders
> dismantle the scaffolding they used to build your house before you
> moved in? That scaffolding served a valuable purpose, but it's not
> part of the house!

Non sequitir, an image is not a house.

>> In fact, when I had problems with the CI image, it really brought into
>> focus the trouble of having to "trust" the image we ultimately
>> release.  I had no idea what was in that image, nor how it was built.
>> I couldn't possibly deploy it.
>
> I trust hand-rolled images far, far less than I do images produced by
> scripts. We can test the latter, at least.

Either can be tested, but I never said hand-rolled, where did you get that?

> Now I realise that the current CI base image has issues, and you know
> what? You know why? Precisely because it is _so hard_ to work with
> images from a command line. It doesn't have to be like this. It
> _shouldn't_ be like this.

That's why I tried to show you my method for managing the seam between
the OS and Smalltalk; because it's simple with other benefits too.

> The whole point of my work on automation is to _remove the human
> element_ from the process.

Yes, I want that too.  YOU said I wanted to hand-roll images, not me.

>>>> And so every image I deploy for a vertical purpose knows how to export
>>>> the library of scripts needed to operate that purpose from the
>>>> command-line.
>>>
>>> snip <<<
>> How can we know the exact ST code of how those general-purpose images are built?
>
> Because (a) it's the update stream and (b) the base image is built by
> a script, from a known base version, that can be debugged and
> reworked.

Right, I just prefer that "script" to be a method in ReleaseBuilder so
it is visible, trunk-maintained and scrutinized and recorded for
posterity in our MC repositories.

>> CI is a vertical application -- it 1) runs test cases against latest
>> code and 2) reports results.  As a tertiary responsibility, we're
>> investigating whether it should 3) be used to build release images.
>> If _all_ the Smalltalk code which builds the release can stay with the
>> image which has withstood the scrutiny of the trunk process, and CI
>> would only "invoke" it, I think it would go a long way toward trusting
>> CI for building release images.
>
> I've built CI stuff for Ruby, Smalltalk and C# code. I've used it with
> Java and Scala. Only one language on that list has been a pain in the
> axe every. single. step. of. the. way. And it's Smalltalk. Why?
> Because we have an obsession with hand-rolling hand-crafted binary
> artifacts lovingly assembled by hand. That's fine for an individual
> user's image. It's rubbish when you want to try and understand what
> this blob of stuff actually contains.

YOU don't have that obsession, so why are you having pain?

I don't have that obsession either; I don't think anyone does but
we've been slow to make our system self-building.  I just wish you
were more open to Squeak playing a role in its own advancement by
putting the Smalltalk-portions of the upgrade script in the image
rather than by some invisible text file out on the internet somewhere
that isn't tracked or scrutinized.

>> Any individual should be able to "make" an equivalent 4.5 solely from
>> a 4.4, via code visible in the image.
>
> An individual _should not have to_.

I said "should be _able_ to".  I totally agree with you about "should
not have to."

> They should be able to download a
> random CI-built image, knowing that it _works_ because the CI
> published the test results for that image. The image should be
> automatically built, tested and deployed by a completely deterministic
> build process.

What is "deployed?"  To me that means, pushed to the location for
public-consumption (e.g., ftp.squeak.org).  If so, just the other week
you said that the "backup copy" out on ftp.squeak.org should be
verified manually.

    http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175304.html
    http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175330.html

I just read those again --  So, you want images to be built by code in
GitHub.  Really, that's fine, but _all I'm asking_ is to move lines
10-13 of release.st into the image, perhaps to the top of
#prepareNewBuild.  That's it!

(Note:  Line 12 should be changed to use the in-image Form from,
(MorphicProject class>>#defaultBackgroundForm)).

> Being able to update your image from some ancient thing is great, and
> we should preserve it, but _I do not want that_ as a means of building
> an artifact for the general public to consume.>

> But this discussion is just going to end up with you saying that
> unloading is how you get a minimal image and me saying that building
> up an image is how you get a full-fat image.
>
> frank
>