Hi doru
We already changed to build not from a snapshot (the one published on regular
basis but manually by marcus)
but from the latest jenkins build. Like that we do not need to load a bunch of
versions.
In addition benjamin showed to marcus the tools he built with camillo to
support integration.
I should sync with them because we would like to have more and more tools to
help us avoiding manual work
and that other people can review fixes and press the button ok without stress,
like that sven, alain, ben, igor
can integrate without stress.
Now for the smaller image:
Context: we need to see because we cannot simply take a small image and load
the latest packages.
Why? because some changes were made knowing that the system was in a
given state.
I hope that in the future we will always be able to load from the
latest package versions but this is not as simple as that.
Exp1:
Now we can try and see. For example if we take the first 1.4alpha and
load the list of packages listed in the latest versions
of scriptLoader package. This could show some potential problems to
upgrade directly to the latest versions of packages.
If you want to help this would be a cool experience to do. With script
loader you can simple ask scriptLoader to load a set of packages.
Exp2:
The second step is to see if it makes sense to manage Core Image with
Metacello or if in addition to the list of packages
we can load the tools manage with metacello (notice that it would mean
also the packages that we will move out of current core):
How much times does it take to load the packages and projects of tools
that would be in Pharo (not Core) and check the time to do it.
We can measure that from a version of core that we consider as
a potential seed and/or
with a version that would get some stuff loaded (and would
correspond to the latest build).
Stef
On Mar 2, 2012, at 10:06 AM, Tudor Girba wrote:
> Hi,
>
> I believe everyone agrees that one important goal in Pharo is to get
> to a small code/kernel/seed. During the Pharo Sprint at Bern we saw
> that the only reason for now having a unified image is just a
> temporary convenience that stems from two things:
> 1. Until Pharo 1.3, the core team worked in the core image, and this
> was frustrating because they were missing proper tools
> 2. After 1.3, building a pharo image out of a seed image was perceived
> as being too long and not fitting for the process of integration
>
> It's clear that the core team needs development tools. However, we
> think that 2 can be actually quite cheap if the build starts from the
> latest seed, and not from the original seed of 1.4 as it currently
> seem to happen. If this would be fast, we could go back to having one
> seed image (I call it seed just to avoid confusion and wrong feelings,
> but you can call it anyway you want) out of which the Pharo
> distribution (like the current image is) is built. The core team would
> work on this distribution, and Jenkins would do the rest. By switching
> the distribution build to work with the latest seed, we can probably
> reduce the amount of build time to a couple of minutes (at least this
> is what we saw during a couple of quick tests).
>
> Regarding the flow of the integrator, we saw that actually, when
> multiple changes need to be integrated, you can base the second change
> on the image that already exists locally, without needing to wait
> until Jenkins finishes.
>
> I would be interested in providing help. So, what do you say?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
