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