On 25 February 2013 15:35, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote:
>> On 25 February 2013 14:49, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> >
>> > On 2013-02-25, at 15:33, Frank Shearar <frank.shearar at gmail.com> wrote:
>> >
>> >> On 14 February 2013 16:50, Frank Shearar <frank.shearar at gmail.com> wrote:
>> >>> No, this takes the Trunk image as is and runs the job. No stripping
>> >>> has occurred. Noone's actually said "oh, that's a sane idea someone
>> >>> should do that" yet (except possibly for you, by virtue of not saying
>> >>> "are you crazy?" :) ), so I haven't done it yet.
>> >>>
>> >>> So the installation is essentially a no-op.
>> >>>
>> >>> With green lights on these builds, we can now verify that removing
>> >>> these packages won't break anything. At least, to the limit of the
>> >>> tests, which isn't much at all. So if we _do_ actually strip these
>> >>> guys out of Trunk, the builds should stay green. If they don't, we'll
>> >>> need to roll back the change and investigate.
>> >>>
>> >>> But I don't actually know how to strip them out of Trunk. I _suspect_
>> >>> it'll be via a Monticello config map of some description.
>> >>
>> >> Anyone? Bert? How do we strip packages out of Trunk?
>> >
>> > Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating.
>>
>> Given that we're early in 4.5's release cycle, if we do this kind of
>> thing - stripping unnecessary things out of trunk - we ought to do it
>> now rather than later. And announce loudly what we're doing, why, and
>> how people can load in their favourite not-Core packages.
>
> NO.
>
> If Squeak developers work with images that contain just "their favourite
> non-Core packages" then none of the non-Core packages get maintained.

Clearly we disagree quite a bit on this, but I don't think anyone
should actually _work_ on a Core image. _Noone_ should be able to work
effectively in a minimal image because such a thing wouldn't even have
a Browser!

> It is important to work on making packages loadable and unloadable, but
> you do not need to break the trunk image in order to accomplish this.

Who's breaking trunk? I want to remove packages that are already
unloadable, and have CI jobs that run every time Trunk updates that
verifies that the packages can (a) reload and (b) run as well as we
already know now (which is not very). To be precise: Universes (for
example) might be smashed beyond recognition, and there is no way to
know, because it has something like 23% method coverage.

Removing these packages from Trunk _will_ affect people updating from
Trunk, I agree. How else do we make Trunk simpler, if not by removing
stuff?

(It's also simple enough to reinstall your favourite packages:
Installer squeakmap update; install: 'WhateverItIs (someVersion)'.)

> Also, please recognize that not everybody wants to do all their work in
> a clean image built by a robot. I for example do most of my work in a
> Squeak3.11alpha image that has been continuously updated from the update
> stream for quite a while. I also periodically check things against a
> fresh 4.4 image, but my usual pattern is to use one image over a long
> period of time with the trunk update stream, and most of my updates to
> trunk come from that old image.

OK, but then we can't have a minimal core without an entire reboot. I
mean, seriously, making a minimal core by unloading packages is an
order of magnitude harder when you cannot ever actually unload the
packages!

So, given the resistance to my slow, gradual unwinding of the tangle,
what's your counterproposal?

frank

> Dave
>
>
>>
>> We have CI tests for the packages (well, the packages I chose as the
>> first victims) showing that they can be loaded into a Trunk image, and
>> while the test coverage is dismal, that just means we don't know
>> whether they work while in Trunk.
>>
>> I'm _not_ about to go and start unloading packages without significant
>> buy-in, but I really do think we ought to actually start working
>> towards a lean, minimal, modular core. That will, of necessity, cause
>> disruption to people updating from trunk. The ReleaseBuilder script or
>> CI job can re-add these packages so that people downloading an image
>> see no change.
>>
>> frank
>>
>> > - Bert -
>> >>> frank
>> >>>
>> >>> On 14 February 2013 16:44, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >>>> OK
>> >>>>
>> >>>>    https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh
>> >>>>
>> >>>> executes
>> >>>>   XML-Parser.st
>> >>>>
>> >>>> which contains
>> >>>>
>> >>>> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'.
>> >>>>
>> >>>> HDTestReport runPackage: 'XML-Parser'.
>> >>>>
>> >>>> "Throw away the dirty image."
>> >>>> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot:
>> >>>> false andQuit: true ].
>> >>>>
>> >>>>
>> >>>> I assume this operates on a trunk image which has the XML-Parser removed?
>> >>>>
>> >>>> In which script does that happen?
>> >>>>
>> >>>> --Hannes
>> >>>>
>> >>>> On 2/14/13, Frank Shearar <frank.shearar at gmail.com> wrote:
>> >>>>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st
>> >>>>>
>> >>>>> They all get triggered by this guy, who I aim to replace with some
>> >>>>> Ruby (because I'd really, really, REALLY rather write Ruby than
>> >>>>> shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh
>> >>>>>
>> >>>>> So the jobs only differ in their command: `./run-test.sh Control`,
>> >>>>> `./run-test.sh XML-Parser`, and so on.
>> >>>>>
>> >>>>> frank
>> >>>>>
>> >>>>> On 14 February 2013 16:34, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >>>>>> 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
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >
>> >
>