you can find the current list of packages in script loader latest version. Now marcus is right on the difficulties we will find :)
Stef On Mar 2, 2012, at 1:11 PM, Stéphane Ducasse wrote: > 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" >> > >
