Great

where can I see what the script is doing for example for XML-Parser?

Which script does the job?

http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/

--Hannes

On 2/14/13, Frank Shearar <frank.shearar at gmail.com> wrote:
> We also now have builds for XML-Parser, Nebraska and Universes (for
> what it's worth: the code coverage is abysmal).
>
> frank
>
> On 13 February 2013 15:23, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> Yes, thank you for the clarification, Frank. This makes a lot of sense
>> to me and I hope that others follow this line of reasoning.
>>
>> --Hannes
>>
>> On 2/13/13, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> On 13 February 2013 12:45, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>>> Frank
>>>>
>>>> If I understand you correctly you want to do the following
>>>>
>>>> 1) unload some once packages from trunk. The packages are taken from
>>>> what is in the list in #unloadAllKnownPackages.
>>>>
>>>> 2) add a trunk method
>>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload
>>>>
>>>> 3) add CI build jobs which do
>>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests
>>>> on the loaded packages.
>>>>
>>>> 4) People use the result of 3) for regular work. This is the "full"
>>>> 4.5 image as we have of now only that we have less in trunk and the
>>>> unlodable packages reside in their own repositories.
>>>>
>>>> Steps 2..4 are done repeatedly.
>>>>
>>>> Is this what you mean?
>>>
>>> Yes. Perhaps with a nicer name than
>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload. Maybe
>>> #loadBasicPackages or something.
>>>
>>> My main aim is to invert the approach we've had up until now, and
>>> _enforce_ the clean separation of these packages from the Core. I want
>>> it to be difficult to add a dependency from the Core to these
>>> packages.
>>>
>>> frank
>>>
>>>> --Hannes
>>>>
>>>> On 2/13/13, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>> On 13 February 2013 11:22, David T. Lewis <lewis at mail.msen.com> wrote:
>>>>>> On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote:
>>>>>>> Yanni,
>>>>>>>
>>>>>>> I think St??phane refers to the original Pharo manifesto which
>>>>>>> clearly
>>>>>>> states "no backward compatibility".  http://code.google.com/p/pharo/
>>>>>>>
>>>>>>> However the current Pharo web page has a mission statement
>>>>>>>    http://www.pharo-project.org/about
>>>>>>> sets a much more moderate tone.
>>>>>>>
>>>>>>> In any case in this thread we want to move on towards a Squeak core
>>>>>>> and learn from the Pharo experience as much as possible. Please let
>>>>>>> us
>>>>>>> not digress from this important topic.
>>>>>>>
>>>>>>> Maybe we should follow both at the same time
>>>>>>>
>>>>>>> Let me call it
>>>>>>> - the Pavel Krivanek approach and
>>>>>>> - the
>>>>>>>      SmalltalkImage unloadAllKnownPackages
>>>>>>>   approach
>>>>>>>
>>>>>>> BTW
>>>>>>> #unloadAllKnownPackages
>>>>>>>
>>>>>>> used to work in Squeak 4.1, see
>>>>>>>
>>>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.html
>>>>>>>
>>>>>>> So there is no reason why we should not manage to get it working
>>>>>>> again
>>>>>>> in Squeak 4.5alpha.
>>>>>>>
>>>>>>> And Pavel's approach may be followed in parallel. Because fixing one
>>>>>>> thing will help the other and vice-verse.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Exactly so. That is what I intended when I mentioned
>>>>>> #unloadAllKnownPackages.
>>>>>> Thanks for stating it so clearly.
>>>>>
>>>>> While we're being clear about what's clear :) I'm wanting to _lose_
>>>>> #unloadAllKnownPackages, and replace it with a
>>>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a
>>>>> bunch of new jobs running those unloaded packages' test suites.
>>>>>
>>>>> That way, the thing called Squeak4.5-nnnn.image still contains what
>>>>> Squeak4.5-${whatever_current_is}.image, only the essence of trunk -
>>>>> what SqueakTrunk produces - shrinks.
>>>>>
>>>>>> Dave
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>