Goran, Cees --
Thanks for taking a look! Your edits are very helpful.
I assumed pretty much everything I wrote on those 3 pages would be heavily edited :) I just wanted to get the ball rolling by creating at least a 0.1 draft of the Swiki pages...
Goran:
1. Definition of "Core packages" --No argument. I tried to indicate that talking about "core" packages in 3.4 is pretty ambigous. --I liked Cees's note 2. Lists of classes/categories --These lists were intended to be a throw-away first draft, as I tried to indicate ----I hope/expect that the community will edit those pages and make 'em more accurate and helpful --It was helpful to me, at least, to get an initial idea of the possible package boundaries 3. Becoming a steward --I tried to indicate that becoming a Steward is not automatic by *any means* ( see http://minnow.cc.gatech.edu/squeak/3090 ) --Thanks for editing http://minnow.cc.gatech.edu/squeak/3070
Are the MCP the collective Steward for Morphic, yet? Ditto KCP for the Kernel?
Thanks, Brent
-----Original Message----- From: goran.hultgren@bluefish.se [mailto:goran.hultgren@bluefish.se] Sent: Thursday, March 06, 2003 4:22 PM To: Discussing the Squeak Foundation Cc: Squeak-Dev (E-mail) Subject: Re: [Squeakfoundation]Stewards and Squeak Packages
Hi!
"Brent Vukmer" bvukmer@blackboard.com wrote:
Please review the following Swiki pages: "Core Packages" ( http://minnow.cc.gatech.edu/squeak/3084 ) "3.4 Core Packages" ( http://minnow.cc.gatech.edu/squeak/3085 ) "Stewards for Core Packages" ( http://minnow.cc.gatech.edu/squeak/3088 )
I looked them over and wrote two comments. Well, one on "Core packages" and one somewhere else... Anyway, in short:
1. I disagree with the definition of "core package". Can be debated of course. 2. I am a bit uneasy of these pages with long lists of classes/categories. Are they really going to be kept updated? Consider me skeptic. 3. I like the "Stewards" stuff. And Squeak estate is also a nice pun with some meaning. But we may take it a bit easy on the signing up part.
I mean - we shouldn't just let "anyone" sign up as a Steward for a core package without due discussion and some form of agreement on these lists. I know we don't have a formal process or anything like that - but still. you can't just grab something and call yourself a Steward.
If there is anything we Guides should take responsibility for then it is to steer this process of dishing out Stewardships.
I think that the "Stewards for Core Packages" page is a decent beginning for a Stewards sign-up sheet.
Yes, but I took the liberty of typing in a few remarks according to what I wrote above. Ok?
regards, Göran
Hi Brent and all!
"Brent Vukmer" bvukmer@blackboard.com wrote:
Goran, Cees --
Thanks for taking a look! Your edits are very helpful.
I assumed pretty much everything I wrote on those 3 pages would be heavily edited :) I just wanted to get the ball rolling by creating at least a 0.1 draft of the Swiki pages...
Yeah, good initiative.
Goran:
- Definition of "Core packages" --No argument. I tried to indicate that talking about "core" packages in 3.4 is pretty ambigous. --I liked Cees's note
Well, he sortof defined yet another meaning but... hmmm. I think we should try to keep these package groups as few as possible. Martins suggestion simplified my own first stab at a grouping and he suggested simply two groups - "core" and "extra".
Cees may of course have good arguments backing it up - but why do we need to separate what Martin (and I) would like to call "core" into "core" and "base"?
In short - I want the groups to reflect some form of semantical difference and not just domain. And the semantic difference between "core" and "extra" is very clear. But what is the difference with class Browser and class Collection? Why should one be called "core" and the other "base"?
Sorry to be rambling, but I still think package grouping is a very important thing for us to clear up. Otherwise chaos may very well ensue.
- Lists of classes/categories --These lists were intended to be a throw-away first draft, as I tried to indicate ----I hope/expect that the community will edit those pages and make 'em more accurate and helpful --It was helpful to me, at least, to get an initial idea of the possible package boundaries
I am just tired of redundant swiki pages forgotten by the author that aren't up to date. And I also don't like to have the "reference manual" of Squeak in a Swiki - I want that *inside Squeak*. You know - the classic problem of keeping two different places in synch. Why would someone remember to edit this page when a class is added or removed?
But you had one nice point though - as a historic record it may serve some form of use. But then I would not create a page *for each class* - it would suffice with an annotated list. Though I still would rather likely look inside the image, but hey... we are all different! :-)
- Becoming a steward --I tried to indicate that becoming a Steward is not automatic by *any means* ( see http://minnow.cc.gatech.edu/squeak/3090 )
Yes, I actually saw that when I already had posted my mail and had edited a few pages. But anyway - it's good to be clear on this.
--Thanks for editing http://minnow.cc.gatech.edu/squeak/3070Are the MCP the collective Steward for Morphic, yet? Ditto KCP for the Kernel?
Well, KCP has clearly stated that intent. I am not so sure about MCP - to my ears it has sounded like a "one shot". But if they are interested I think they seem qualified - their work so far looks impressive (though I haven't really looked at the changes).
I also assume that there are quite a few other interested parties in Morphic. Like the Croquet guys for example.
Thanks, Brent
Hey, thank *you*. One last word of advice - it is easy to become excited and create a lot of Swiki pages. Please remember (as I assume you all do) that they need to be kept up to date too...
Actually - it would be nice if the darn Swiki could send out "please update this page, it was 325 days since last edit" to people that in some way have signed up as "moderator" for that page. Just a thought.
regards, Göran
On Fri, 2003-03-07 at 09:33, goran.hultgren@bluefish.se wrote:
Cees may of course have good arguments backing it up - but why do we need to separate what Martin (and I) would like to call "core" into "core" and "base"?
Of course I have. Extremely good arguments. And I completely, totally, and utterly fail to understand that I haven't convinced you yet ;-).
'kernel', 'core' and 'base' are three logical levels of Squeakness, and I think that if the 'official' distributions distinguish these levels we have a useful triad of starting point for alternative distributions. Some arguments:
1. It's a triad. Three is a holy number. That's Good[TM] :-).
2. 'kernel' is the absolutely minimal starting point for anyone to do anything with Squeak (the VM plus enough code to do a fileIn, including some no-brainers like numbers, collections). Like an OS kernel, it knows how to bootstrap itself to higher levels (where a Unix kernel bootstraps to the point where it can execute '/sbin/init', I think it is logical to have a Squeak kernel bootstrap to the point where it can file in the first command line argument and execute the preamble/postamble).
It is not really useful for most people as a stand-alone distribution, but helps a) to focus the attention of people who want to work on the kernel; b) to aid people who *do* think they have an application for it. Compare it to the various Linux single-floppy distros: for 99.95% of the Linux users, the fact that you can download and compile a single kernel is useless, but it is immensely helpful for these people. c) prevent forking in the case that groups want to branch out, like Squeak-E. If Squeak-E (for example) needs kernel patches, this can be discussed in a small and concentrated forum; the scope of the changes can be discussed much better if you know what the overall API is the kernel offers. Squeak-E is currently dormant just because of the dauntingness of the task; a 'kernel' to look at would immensely help this and similar efforts.
3. 'core' is the absolutely minimal starting point for 'Squeak as a development environment'. It is the 'kernel' that has been 'bootstrapped' into an IDE - you get a GUI (MVC? Morphic?), class browser (Regular browser? RB?). For developers, this might be a useful starting point - there's a minimal amount of clutter, and you can start hacking right away. A good analogy is the image that VisualWorks provides: it opens with transcript, (refactoring) browser; it lacks some 'advanced' tools like StORE (because people want to use CVSt, or ENVY, Cincom isn't making this choice for you), but has all that's necessary to further adorn your dev env (in the VW case, the Parcel Loader; in Squeak's case, you probably want to include the SqueakMap browser).
4. 'base' is the starting point for end users. It's probably very close to Squeak-as-we-know-it-now. Compare it with installing the average end-user-focused Linux distribution's 'workstation' configuration; you get some web browser, a mail reader, ... - all arbitrary choices made for you by a third party, but good enough to get started. It is a canonical set of user-directed tools (and quite likely it'll be a strict superset of 'core' so you get all the development stuff thrown in for free), which basically says "this gets you going, the tools in here are maybe not *exactly* what you want, but we've tested them and think they are good enough for you to be able to work with them". Then, as a user progresses, he/she will find that FooBrowser is a better package than BarBrowser if you want to browse a lot of javascript-intensive sites, so two button clicks later, FooBrowser is kicked out and BarBrowser is loaded from SqueakMap.
Now, how's that for an excellent set of arguments.
Of course, the *exact* borders between the three levels are largely fractal in nature - as you zoom in, you get more and more stuff to discuss ;-). Magnitude might belong in the Kernel, but all methods currently in Magnitude? Probably not. However, the issue is not whether we can at this point in time establish sharp borders - we can not and we will never be able to do so, that's the nature of our environment. That's why we seem to be so good at discussing it and then deciding upon it, and that is what we'll have to do many, many times.
The issue is that I think that this is a very minimal set of, let's call it, 'blessed configurations' of Squeak that caters to the maximal number of uses. Leave 'kernel' out, and you don't have anything for people that want to drive network switches or unmanned subs with it. Leave 'core' out, and you force e.g. application server developers to either do a large bootstrap from 'kernel' or start stripping out loads of stuff from 'base'. Leave 'base' out, and most newbies never will take a second look at Squeak, let alone teachers, etcetera.
This is the minimal set of configurations that is horizontally targeted. I cannot prove it, but I think it makes a lot of sense.
Of course, I do hope that we'll continue to have vertically targeted configurations: - Squeakland configuration, optimized for education; - Plugin configuration, optimized for Flash-like things; - Webdev configuration, with Comanche+Seaside and other goodies preloaded; - Darkside configuration, geared to managers (presentation package and a mind-numbing game like Solitaire); - whatever.
Hi Cees and all!
Cees de Groot cg@cdegroot.com wrote:
On Fri, 2003-03-07 at 09:33, goran.hultgren@bluefish.se wrote:
Cees may of course have good arguments backing it up - but why do we need to separate what Martin (and I) would like to call "core" into "core" and "base"? =20
Of course I have. Extremely good arguments. And I completely, totally, and utterly fail to understand that I haven't convinced you yet ;-).
I play hard to get, that is all. :-)
'kernel', 'core' and 'base' are three logical levels of Squeakness, and I think that if the 'official' distributions distinguish these levels we have a useful triad of starting point for alternative distributions. Some arguments:
- It's a triad. Three is a holy number. That's Good[TM] :-).
Actually a better argument than people may think.
- 'kernel' is the absolutely minimal starting point for anyone to do
anything with Squeak (the VM plus enough code to do a fileIn, including some no-brainers like numbers, collections). Like an OS kernel, it knows how to bootstrap itself to higher levels (where a Unix kernel bootstraps to the point where it can execute '/sbin/init', I think it is logical to have a Squeak kernel bootstrap to the point where it can file in the first command line argument and execute the preamble/postamble).=20
It is not really useful for most people as a stand-alone distribution, but helps a) to focus the attention of people who want to work on the kernel; b) to aid people who *do* think they have an application for it. Compare it to the various Linux single-floppy distros: for 99.95% of the Linux users, the fact that you can download and compile a single kernel is useless, but it is immensely helpful for these people. c) prevent forking in the case that groups want to branch out, like Squeak-E. If Squeak-E (for example) needs kernel patches, this can be discussed in a small and concentrated forum; the scope of the changes can be discussed much better if you know what the overall API is the kernel offers. Squeak-E is currently dormant just because of the dauntingness of the task; a 'kernel' to look at would immensely help this and similar efforts.
Sounds good. Should we have *one* official kernel and then of course people can register their own variants on SM? I think so.
- 'core' is the absolutely minimal starting point for 'Squeak as a
development environment'. It is the 'kernel' that has been 'bootstrapped' into an IDE - you get a GUI (MVC? Morphic?), class browser (Regular browser? RB?). For developers, this might be a useful starting point - there's a minimal amount of clutter, and you can start hacking right away. A good analogy is the image that VisualWorks provides: it opens with transcript, (refactoring) browser; it lacks some 'advanced' tools like StORE (because people want to use CVSt, or ENVY, Cincom isn't making this choice for you), but has all that's necessary to further adorn your dev env (in the VW case, the Parcel Loader; in Squeak's case, you probably want to include the SqueakMap browser).
So "core" is the baseline that you normally (unless building something of your own on top of a kernel directly) "know" is there. And it is a superset of the official "kernel" I assume.
- 'base' is the starting point for end users. It's probably very close
to Squeak-as-we-know-it-now. Compare it with installing the average end-user-focused Linux distribution's 'workstation' configuration; you get some web browser, a mail reader, ... - all arbitrary choices made for you by a third party, but good enough to get started. It is a canonical set of user-directed tools (and quite likely it'll be a strict superset of 'core' so you get all the development stuff thrown in for free), which basically says "this gets you going, the tools in here are maybe not *exactly* what you want, but we've tested them and think they are good enough for you to be able to work with them". Then, as a user progresses, he/she will find that FooBrowser is a better package than BarBrowser if you want to browse a lot of javascript-intensive sites, so two button clicks later, FooBrowser is kicked out and BarBrowser is loaded from SqueakMap.
Would "base" also be the boundary of everything maintained by stewards? I mean - does base define what we call "Squeak"? Does it include all of the stuff that we - as a community - considers to be "ours"?
I would like to have it that way, anyhow.
Now, how's that for an excellent set of arguments.
Yes, I like it and I buy it.
Of course, the *exact* borders between the three levels are largely fractal in nature - as you zoom in, you get more and more stuff to discuss ;-). Magnitude might belong in the Kernel, but all methods currently in Magnitude? Probably not. However, the issue is not whether we can at this point in time establish sharp borders - we can not and we will never be able to do so, that's the nature of our environment. That's why we seem to be so good at discussing it and then deciding upon it, and that is what we'll have to do many, many times.=20
Of course. But it is good to get at least *something* defined so that we can enrich our language. Now - if I say to you that I consider something to belong in base instead of core - then you will understand what I am talking about.
So, to get practical - should we introduce these three as Categories in SM? I would think so. And then of course a fourth is needed - "extra" or "other" or something. And should this category be mandatory? Probably. I will wait and see what people say and then we could perhaps write these categories down. You know, nail the name and a oneline description plus a URL to a Swiki page that explains it further. (Yep, each category can actually have a URL associated that explains it in detail, I have only used it here and there).
And of course, I would like more help in maintaining the SM category tree. If anyone has ideas I would like to hear them.
The issue is that I think that this is a very minimal set of, let's call it, 'blessed configurations' of Squeak that caters to the maximal number
I would rather like to call it "package groups". I think.
of uses. Leave 'kernel' out, and you don't have anything for people that want to drive network switches or unmanned subs with it. Leave 'core' out, and you force e.g. application server developers to either do a large bootstrap from 'kernel' or start stripping out loads of stuff from 'base'. Leave 'base' out, and most newbies never will take a second look at Squeak, let alone teachers, etcetera.=20
This is the minimal set of configurations that is horizontally targeted. I cannot prove it, but I think it makes a lot of sense.
Agree.
Of course, I do hope that we'll continue to have vertically targeted configurations:
- Squeakland configuration, optimized for education;
- Plugin configuration, optimized for Flash-like things;
- Webdev configuration, with Comanche+Seaside and other goodies
preloaded;
- Darkside configuration, geared to managers (presentation package and a
mind-numbing game like Solitaire);
- whatever.
Sure, those will arrive when SM goes forward. We need versions in SM first. :-)
regards, Göran
squeakfoundation@lists.squeakfoundation.org
-
Brent Vukmer -
Cees de Groot -
goran.hultgren＠bluefish.se