Yeah, so there are a number of forces at work, right? Is a bigger image
"right?" Or is worrying so much about rigor that one overlooks the utter
harmlessness of the build tools "right?"

I would certainly tell you that in this case, I prefer the latter, but then
I'm forced to fork Lukas' code... people will get mad at me for adding
classes... etc... so probably if we called a vote on it, my job would be to
make sure that the build infrastructure gets unloaded before the artifacts
are archived.

p.s.

You're dead right, it integrates JUnit XML output (as grokked by
Hudson/Jenkins) with SUnit, but without modifying SUnit AFAICT (it seems
like a pretty elegant solution to me. I'm not hating it. This is a good
sign!) The actual build scripts are external to the image (on the file
system) so the impact of loading it is pretty negligible, as nothing depends
on it.

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

> On 9 September 2011 12:36, Casey Ransberger <casey.obrien.r at gmail.com>
> wrote:
> > 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.
>
> So the answer is to fall on the side of "make it work" because
> crossing over to the "make it right" side? :)
>
> Or: I'd rather we had SOME confidence in the build, than NO confidence.
>
> frank
>
> > 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
> >
> >
> >
> >
>
>


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