[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic.
[packages for Basic, like DVS, SAR] IMO Basic should include PackageInfo, because it is a useful unit of filing stuff in and out that (a very lightweight replacement for one function changesets get abused for). DVS and SAR I am less sure about. In particular, DVS seems like it might be temporary, in the sense that the Monticello stuff will replace it as infrastructure. OTOH, maybe I'm just faliing to realize the benefits of how easy it is to issue an update that installs/uninstalls well-packaged stuff. Which, BTW, we need to define and start paying attention to - stuff that doesn't uninstall cleanly is badly packaged, and should not be included in Basic.
Daniel
goran.krampe@bluefish.se wrote:
Ok, back to the issue at hand: SM. And IMHO DVS, SAR and Package Loader. And perhaps one or two more I am forgetting right now. My reasoning above may sound like I don't want to introduce SM into the image - but in fact I do. :-) But not as "just another changeset". I want them *installed as packages*.
What this means in practice is the following:
We should issue updates through the update stream that installs these puppies using SM! The SM bootstrap changeset (the one that you get if you do the "Open packag loader") makes it look like SM itself was installed through SM (though of course it wasn't).
I know that Scott Wallace earlier argumented to put SM into the image - and I strongly objected. I still object to simply "filing it in" just like *any changeset*.
In short - we can issue an update that simply runs the bootstrap. We can keep the bootstrap code in place for a while.
(Then there's Andreas' new stuff which supports update streams on individual packages, which I haven't looked at closely yet... I'm not sure if that would make a big difference for this particular case.)
I don't think so. I may try it out but I can't see how they have anything to do with us just yet. That package could OTOH be a candidate for Basic of course - just like DVS, SAR etc.
Phew - so what do you all say? Does my analysis above sound reasonable? I find it strange that it seems so hard to define what things are - we really are creatures of habit. Hard to let go! :-)
- Doug Way
regards, Göran _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi Daniel and all!
Daniel Vainsencher danielv@netvision.net.il wrote:
[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic.
Well, perhaps I didn't make myself clear. And these things are hard to reason about. What I meant is that the update stream feeds updates that is producing the Minimal *image*. BUT... with the packages installed turning it defacto into Basic.
If we said that the update stream is aiming to produce Basic then... What does that mean? Does it mean that we aren't "packageifying" the stuff that we intend to have in Basic? Nope. PackageInfo is a package. And so is SM.
IMHO this means we are in fact working towards Minimal when we consider the *image* (without installed packages) but if we consider *with packages* then we surely are aiming for Basic.
Whatever - I hope you see my point.
[packages for Basic, like DVS, SAR] IMO Basic should include PackageInfo, because it is a useful unit of filing stuff in and out that (a very lightweight replacement for one
Definitely. And btw, I have come to realize that PackageInfo and SMCard (future SMPackage) don't necessarily map "one to one". This is important.
function changesets get abused for). DVS and SAR I am less sure about. In particular, DVS seems like it might be temporary, in the sense that the Monticello stuff will replace it as infrastructure. OTOH, maybe I'm just faliing to realize the benefits of how easy it is to issue an update that installs/uninstalls well-packaged stuff. Which, BTW, we need to define and start paying attention to - stuff that doesn't uninstall cleanly is badly packaged, and should not be included in Basic.
That I agree with. Even though I personally will not give uninstall much thought for a long time. :-)
Including DVS (which currently uses the same internal code as Monticello I think) would be good to make sure people move over to that kind of fileout much more suitable for packages.
Daniel
regards, Göran
On Thu, 22 May 2003 goran.krampe@bluefish.se wrote:
Definitely. And btw, I have come to realize that PackageInfo and SMCard (future SMPackage) don't necessarily map "one to one". This is important.
Can you elaborate on this?
Including DVS (which currently uses the same internal code as Monticello I think) would be good to make sure people move over to that kind of fileout much more suitable for packages.
Well, all that's actually needed for this is PackageInfo (and maybe some super-simple UI like right clicking on a category name in the PackagePaneBrowser and having a "file-out package" option).
DVS and Monticello don't share any code, by the way; they both depend on PackageInfo, but that's it.
Hi Avi!
Avi Bryant avi@beta4.com wrote:
On Thu, 22 May 2003 goran.krampe@bluefish.se wrote:
Definitely. And btw, I have come to realize that PackageInfo and SMCard (future SMPackage) don't necessarily map "one to one". This is important.
Can you elaborate on this?
Yes. SMPackage is tyically a "published" package made for consumption/use of others. A PackageInfo-package may be simply an internal component of such a published package. In short - there may be more PackageInfos than there are SMPackages but there will typically always be one PackageInfo per SMPackage. :-)
Looking at CVS again I would say that PackageInfo corresponds a tad with the "modules" you can define in the CVSROOT/Modules file. Partitions of the project suitable for the developers.
And SMPackage again - is a "public" package used by others.
So my conclusion is that both concepts are valid and disjoint but we should try to NOT introduce any *more* of these "kinda-module-thingies" into the Squeak world. :-)
Including DVS (which currently uses the same internal code as Monticello I think) would be good to make sure people move over to that kind of fileout much more suitable for packages.
Well, all that's actually needed for this is PackageInfo (and maybe some super-simple UI like right clicking on a category name in the PackagePaneBrowser and having a "file-out package" option).
DVS and Monticello don't share any code, by the way; they both depend on PackageInfo, but that's it.
Aha, ok. I remembered wrong. I thought sometime you said that you had moved DVS over to use the same internal code that Monticello does.
regards, Göran
I just wanted to mention that the idea of including the SM bootstrap in the update stream sounds reasonable to me.
And...
On Thursday, May 22, 2003, at 12:27 PM, goran.krampe@bluefish.se wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic.
Well, perhaps I didn't make myself clear. And these things are hard to reason about. What I meant is that the update stream feeds updates that is producing the Minimal *image*. BUT... with the packages installed turning it defacto into Basic.
If we said that the update stream is aiming to produce Basic then... What does that mean? Does it mean that we aren't "packageifying" the stuff that we intend to have in Basic? Nope. PackageInfo is a package. And so is SM.
IMHO this means we are in fact working towards Minimal when we consider the *image* (without installed packages) but if we consider *with packages* then we surely are aiming for Basic.
Yeah, I suppose. I guess it depends on whether you consider the "image" to include these installed packages. Practically speaking, the packages are in the image file, they just weren't added via the update stream. :-) But I see your point.
One other side issue... we may or may not want to move straight to the Basic image and then the Minimal image after that. For example, you could argue that SUnit should be part of the Basic image. (It is a pretty fundamental development tool, although it's not one of the traditional ST80 tools.) In that case, we've already strayed from the Basic image by removing it.
- Doug Way
Hi all!
Doug Way dway@riskmetrics.com wrote:
I just wanted to mention that the idea of including the SM bootstrap in the update stream sounds reasonable to me.
Ok. Of course we need to get the details straight here before we do anything.
And...
On Thursday, May 22, 2003, at 12:27 PM, goran.krampe@bluefish.se wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic.
Well, perhaps I didn't make myself clear. And these things are hard to reason about. What I meant is that the update stream feeds updates that is producing the Minimal *image*. BUT... with the packages installed turning it defacto into Basic.
If we said that the update stream is aiming to produce Basic then... What does that mean? Does it mean that we aren't "packageifying" the stuff that we intend to have in Basic? Nope. PackageInfo is a package. And so is SM.
IMHO this means we are in fact working towards Minimal when we consider the *image* (without installed packages) but if we consider *with packages* then we surely are aiming for Basic.
Yeah, I suppose. I guess it depends on whether you consider the "image" to include these installed packages. Practically speaking, the packages are in the image file, they just weren't added via the update stream. :-) But I see your point.
Good. This point is IMHO important, see below.
One other side issue... we may or may not want to move straight to the Basic image and then the Minimal image after that. For example, you could argue that SUnit should be part of the Basic image. (It is a pretty fundamental development tool, although it's not one of the traditional ST80 tools.) In that case, we've already strayed from the Basic image by removing it.
This proves my point even more! As far as "cutting-stuff-out-and-turning-them-into-packages" we *are* moving towards Minimal.
BUT - we should install those packages back in (those that belong in Basic that is) so that the end result is a not-yet-but-anyway-Minimal image + the packages considered to belongto Basic.
So, no - we aren't straying IMHO. We are doing it exactly right: We cut out packages that are easy to cut out (and it doesn't really matter in which order we do it because *everything* will eventually turn into packages) and we simply install them back in if they belong to Basic. Simple as that.
Now - the question is: Should we issue updates that install packages back in or should we simply maintain a Basic-loadscript that is a tad smart and simply makes sure all packages that belong to Basic are installed? I think I vote for the latter. We could of course issue an update that alerts the user of this loadscript and asks if it should be installed. And later - we can issue updates that check if that loadscript is installed and in that case simple "reinstalls" it so that any newly cut out stuff gets installed back in.
regards, Göran
Daniel Vainsencher danielv@netvision.net.il wrote:
[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic.
I'll agree with this; whilst we clearly want to proceed eventually to having a minimal image I doubt a) that we're going to do it for 3.6 b) that it will be done simply by updates.
We discussed this matter somewhat at last nights Squeak meeting at Craig's place. (Where were you all? Only seven people turned up and all the rest of you missed pizza, beer, soda, doughnuts and great conversation)
Craig's approach to remotely pillaging an image has (much against my original expectations) worked beautifully. The mix of Flow and some very well done proxy design has enabled him to get to a very small image and most importantly to talk to it from a 'sensible' image. Personally I think that the remote part is going to end up far more important than merely shrinking the image. Remote debugging, clusters of images, all sorts of possibilities.
Alongside that work we are expecting that some stuff I am deriving from conversations with Alejandro & co. will make it possible to generate a predefined minimal image from scratch, having learned from Craig's pillaging what really needs to be there along with some thought about what Dan referred to as an 'elegant minimal image'.
Assuming this all works ok we will have a minimal image that can be expanded by remote manipulation to add any components needed including of course the compiler system so that the subject image can simply filein stuff for itself. At that point we can add more subsystems to produce the basic image and then the mongo-kitchen-sink-dancing-baby version. All completely repeatable via comprehensible scripts from well known archived sources. Golly.
All we need is One Million Dollars, to quote Dr. Evil. Unmarked small denomination bills, no consecutive serial numbers, plain brown paper bag.
tim
Tim Rowledge wrote:
most importantly to talk to it from a 'sensible' image. Personally I think that the remote part is going to end up far more important than merely shrinking the image. Remote debugging, clusters of images, all sorts of possibilities.
Which John Sarkela has been telling us for years ;-) And I completely agree!
Michael
Michael Rueger m.rueger@acm.org wrote:
Tim Rowledge wrote:
most importantly to talk to it from a 'sensible' image. Personally I think that the remote part is going to end up far more important than merely shrinking the image. Remote debugging, clusters of images, all sorts of possibilities.
Which John Sarkela has been telling us for years ;-) And I completely agree!
Yup, that's life. Eliot & I (and various other folk from the Manchester Uni. group for example) were trying to get stuff like this done, with some small success, back in 89-90. We didn't consider it actually a new idea even then. Maybe fifteen years later we'll get around to making a good version?
tim
Tim Rowledge tim@sumeru.stanford.edu wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic.
I'll agree with this; whilst we clearly want to proceed eventually to having a minimal image I doubt a) that we're going to do it for 3.6 b) that it will be done simply by updates.
Please read my other post regarding this. I have never thought that the update stream will bring us all the way - not even halway. But the principle is IMHO still a fact - the update stream is *currently* attached to the "image" that is moving *towards* Minimal and not Basic. I agree we are "splitting hairs" or whatever you call it but to me we are doing two things at once and that is muddling the waters:
1. Move towards Minimal. That is what we are doing in 3.6alpa. We are cutting out stuff into packages *including* stuff that will be in Basic (installed as packages).
2. Maintaining the end user experience that the user is sitting in front of Basic. But that means reinstalling packages (ontop of the current not-so-very-but-still-moving-towards-Minimal image) as we go.
In my response to Doug I came down to a conclusion and a proposal how we most easily should do this, see that post.
[BIG SNIP] Otherwise I agree wholeheartedly about Craig's work and support it 200% and really want it to not turn into a fork. Let me repeat that - it is a "clear and present danger" IMHO. But I know Craig knows this and I hope he manages to keep all his work "somehow repeatable and in synch" with the rest of us.
And I also agree that there is no other way we will ever reach a Minimal that has no UI for example. Simply not practical. Go Craig, go.
regards, Göran
squeakfoundation@lists.squeakfoundation.org
-
Avi Bryant -
Daniel Vainsencher -
Doug Way -
goran.krampe＠bluefish.se -
Michael Rueger -
Tim Rowledge