If we wanted to be purists, and I say this with my grumpy tester hat on, we
would leave the build bits in the image, because *ideally* you want to test
exactly what you ship, if it's possible, but nothing depends on this stuff,
and I doubt it will affect the tests, so I'm afraid I'm on the fence about
it. I might start another thread about this.

On Fri, Sep 9, 2011 at 4:33 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 9 September 2011 12:23, Casey Ransberger <casey.obrien.r at gmail.com>
> wrote:
> > Okay, so, here's what we're gonna do. Sort out how to unload it when
> there's
> > more people awake:)
> > It's seriously like six or seven classes in one category. There *must* be
> a
> > way to do this using... Smalltalk.
> > Frank: No, the idea is that you archive the image, and it becomes the
> next
> > trunk image, so that I don't have to make them by hand anymore:) and then
> > you also have a release image ready to rock when all the features are in
> and
> > the tests are clean.
>
> I guess we're talking about subtly different things: I'm looking at
> the problem of "can I assemble an image that passes its tests?" and
> you're looking at the problem of "the latest trunk image passes its
> tests". But then isn't the right thing to do this?:
> * get the latest trunk image
> * run its tests (like from a starter script passed into the image on
> the command line)
> * report the results (which would require a TestRunner capable of
> dumping Hudson-friendly XML, which is probably what the Hudson tooling
> provides...)
>
> Hm. But you COULD write a script that loads whatever build
> infrastructure you need, couldn't you?:
>
> Installer whereever
>    install: 'The build tools'.
>
> "Insert stuff causing the test runner to run and send its output to stdout"
>
> It's not _quite_ what we want, since Hudson reports that the image
> _plus_the_extra_bits_ passes its tests (or not, of course). Pretty
> close, though.
>
> frank
>
> > I'm not installing Gofer over this, I don't need it for anything in the
> base
> > system. Unloading seven classes or whatnot should not be a major problem,
> > I'm just going to have to figure out how to do it. If I have to I'll just
> > install it with a change set so that MC doesn't see it. Then I can just
> tell
> > the system organizer to drop it or whatnot. I'm sure this will be doable.
> >
> > On Fri, Sep 9, 2011 at 4:10 AM, Levente Uzonyi <leves at elte.hu> wrote:
> >>
> >> On Fri, 9 Sep 2011, Edgar J. De Cleene wrote:
> >>
> >>>
> >>>
> >>>
> >>> On 9/9/11 12:58 AM, "Casey Ransberger" <casey.obrien.r at gmail.com>
> wrote:
> >>>
> >>>> This is to rid the build tools from the produced artifact, a nice
> touch.
> >>>> Since
> >>>> we don't have Gofer in Squeak, is there an easy way to do this?
> >>>>
> >>>> --
> >>>
> >>> Port Gofer to Squeak, get rid of all another loaders (Universes,
> >>> Installer,
> >>> SqueakMap),etc.
> >>
> >> Gofer is an API for Monticello. Installer is a general purpose
> >> (un)installer tool, SqueakMap is a package catalog. So no, we won't get
> rid
> >> of them. Universes is abandoned and SqueakMap has similar capabilities,
> so
> >> we'll probably remove it from the system.
> >>
> >>
> >> Levente
> >>
> >>> So you was closer to Pharopatas way of work and avoid many troubles
> >>>
> >>> Cheers.
> >>>
> >>> Edgar
> >>>
> >>
> >
> >
> >
> > --
> > Casey Ransberger
> >
> >
> >
> >
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110909/5c65ea82/attachment.htm