Glamour-core maybe missing from Pharo40/main
Sometimes when I am hacking around the system, I use Monticello to review just what I've changed. In build 40390, I did a <Changes> of Glamour-Core (BernardoContreras.286) against Pharo40/main and got _lots_ of changes. Then it seems that this package is not in Pharo40/main. Should it be? Maybe this is because its an external package - but then its repository is not listed? cheers -ben
Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories. On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc@openinworld.com> wrote:
Sometimes when I am hacking around the system, I use Monticello to review just what I've changed.
In build 40390, I did a <Changes> of Glamour-Core (BernardoContreras.286) against Pharo40/main and got _lots_ of changes. Then it seems that this package is not in Pharo40/main. Should it be?
Maybe this is because its an external package - but then its repository is not listed?
cheers -ben
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.
On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
Sometimes when I am hacking around the system, I use Monticello to review just what I've changed.
In build 40390, I did a <Changes> of Glamour-Core (BernardoContreras.286) against Pharo40/main and got _lots_ of changes. Then it seems that this package is not in Pharo40/main. Should it be?
Maybe this is because its an external package - but then its repository is not listed?
cheers -ben
On 05 Dec 2014, at 15:30, stepharo <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. Uko
On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
Sometimes when I am hacking around the system, I use Monticello to review just what I've changed.
In build 40390, I did a <Changes> of Glamour-Core (BernardoContreras.286) against Pharo40/main and got _lots_ of changes. Then it seems that this package is not in Pharo40/main. Should it be?
Maybe this is because its an external package - but then its repository is not listed?
cheers -ben
On 06 Dec 2014, at 12:10, Yuriy Tymchuk <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. Marcus
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
I agree. Doru On Sat, Dec 6, 2014 at 12:34 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
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> wrote:
On 05 Dec 2014, at 15:30, stepharo <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
-- www.tudorgirba.com "Every thing has its own flow"
Roma was not created in one day. Now if you have energy I have a pretty long list of issues to be fixed. Stef
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.
but this is orthogonal to the original problem. I wrote scriptloader to reset the repo because we had different repositories with different passwords. So the logic is to clean everything. Now we can add the repo of Glamour and it will be reset and reassigned everything. But the right approach is SIMPLY that each package declares its home and scriptloader will be able to reset the repo of each package to their home. This has nothing to do with MC keeping ancestor metadata. So could we stop sending bad signal about our system? Because Pharo is great. Stef
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.
This has nothing to do with that. let us stop talking in the air.
participants (5)
-
Ben Coman -
Marcus Denker -
stepharo -
Tudor Girba -
Yuriy Tymchuk