On 06 Dec 2014, at 12:21, Marcus Denker <marcus.denker@inria.fr> wrote:
On 06 Dec 2014, at 12:10, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 05 Dec 2014, at 15:30, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Le 3/12/14 10:08, Marcus Denker a écrit :
Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories.
Yes because else we can have dangling refs (you remember the mess in Squeak3.9). Now this is why we should have package metadata in the image because we could just reset the repo to their package.
I thought that one of the main ideas of versioning systems was that you keep all the important history things on the server.
Yes, else the image will grow indefinitely (as it does now). a whole 1/3 of our image is meta data from Monticello and Scriptloader. (Pharo4 is 30.9M, but after Scriploader clean and removing MC history, it is just 22,7MB)
And this is already with killing this meta data at every release. If we would keep it, our image would be around 60MB-80MB, that is we would have 4 times more history data than real data. (and the .changes I guess far more than 200MB). All this just does not work.
We need a system that allows sustained growth: meta data of history needs to be outside on a server. Everything else will not work.
One good rule that we should adopt: The artefact of the build server needs to be the release artefact *with no human intervention at all*. No âwe remove that before we releaseâ âwe call that method before we releaseâ. No. Just: What is there is the release. Just that. It will serve as a nice forcing function. A .changes with #condenseChanges called once a year? Nope. Monticello having history data in the image? Not possible. Scriptlaoder having all the sets of packages that made every update ever? Canât be. We would have a much better system *and* much less stress when releasing. Marcus