Scott mentioned awhile ago that he would be releasing a candidate image for 3.4gamma. I thought it might be helpful to at least have a mention of SqueakMap somewhere in one of the introductory windows of the image.
So, here's a proposed paragraph blurb introducing SqueakMap. I thought it might be best located in the "Welcome to..." window, after the very first section but before the "Morphic" section. (The "*here*" link would be a DoIt link which would execute "TheWorldMenu openPackageLoader".)
Or, it could go in ReadMe.txt or somewhere else, but I think the Welcome window might be best. Feel free to improve the wording, etc.
(In theory, we could also have an introduction to the Guides, but I'm not sure that's as important. There's not really any mention of Squeak Central in the intro windows, anyway.)
- Doug
---------------------------------------
<bold>What's new in Squeak 3.4</bold> An exciting feature which has been made available in the 3.4 release is SqueakMap, a package catalog system for Squeak. As of this release, over 100 packages/applications have been added to SqueakMap by members of the Squeak community. You can easily browse and install these packages directly in Squeak by using the SqueakMap Package Loader, which is available from the "open..."/"Package Loader" menu (or, by clicking *here*).
For more information on SqueakMap, see *http://minnow.cc.gatech.edu/squeak/squeakmap*.
Doug Way dway@riskmetrics.com is claimed by the authorities to have written:
Scott mentioned awhile ago that he would be releasing a candidate image for 3.4gamma.
This is good, as is your proposed text.
What isn't good is that I can't quite work out what we've decided will be in the gamma release, nor _how_ we've decided it. Perhaps it's just creeping senility, or maybe it's I forgot to take the tablets. BUT the squeakfixes page is months out of date (at least, http://209.143.91.36/super/415 is) and so are most of the swiki pages describing our supposed process. For example, http://minnow.cc.gatech.edu/squeak/954
Which leaves me a little puzzled as to how I'm supposed to proceed. What have I missed or forgotten?
confused in silicon valley.
Tim Rowledge tim@sumeru.stanford.edu wrote:
Doug Way dway@riskmetrics.com is claimed by the authorities to have written:
Scott mentioned awhile ago that he would be releasing a candidate image for 3.4gamma.
This is good, as is your proposed text.
Agree - good and to the point.
What isn't good is that I can't quite work out what we've decided will be in the gamma release, nor _how_ we've decided it. Perhaps it's just
I think we decided it on this list and that it includes exactly what is in the beta! :-) Doug has taken quite some time/effort to post on the updates we wanted to include before going into beta/gamma of 3.4 and the basic intention behind it all was (also discussed on the list) to simply get 3.4 out he door since it includes all the 3.3 alpha stuff (without Modules of course) and more and we wanted to get a "quick release" so that we can take a breath and start the real work in 3.5.
creeping senility, or maybe it's I forgot to take the tablets. BUT the squeakfixes page is months out of date (at least, http://209.143.91.36/super/415 is) and so are most of the swiki pages describing our supposed process. For example, http://minnow.cc.gatech.edu/squeak/954
Which leaves me a little puzzled as to how I'm supposed to proceed. What have I missed or forgotten?
confused in silicon valley.
Well, currently the Harvesting process is more or less "down" but run temporarily by Doug and Scott in tandem. I don't think the squeakfixes pages are maintained currently. We do have plans on making a new good tool for doing harvesting etc (package centric) but that is still slated for 3.5 I think.
Please correct me if anything above is "wrong".
regards, Göran
goran.hultgren@bluefish.se is claimed by the authorities to have written:
What isn't good is that I can't quite work out what we've decided will be in the gamma release, nor _how_ we've decided it. Perhaps it's just
I think we decided it on this list and that it includes exactly what is in the beta! :-) Doug has taken quite some time/effort to post on the updates we wanted to include before going into beta/gamma of 3.4 and the basic intention behind it all was (also discussed on the list) to simply get 3.4 out he door since it includes all the 3.3 alpha stuff (without Modules of course) and more and we wanted to get a "quick release" so that we can take a breath and start the real work in 3.5.
Yes but there has been quite a number of 'last minute important fixes' traffic, not least a few fixes I consider important. I can't find anything that lets me know if those fixes are queued up anywhere - not even with the magical 'look at internal server' patch. Without the sqfixes page and its brethren I'm stuck. Terribly vexing.
I'd suggest we need to caucus on the issue of some tools to help us handle fixes and changes more effectively in preparation for the onslaught of brilliant ideas that is likely to hit us like a tsunami for 3.5
First suggestion I'd like to make is that the sqfixes page be changed to make use of more targetted editing capabilities of swiki; rather than having to edit the entire chunk of code, it is actually possible to have an edit dooberry for each individual item.
Second nice thing would be some interface so that a) 'ordinary' people can comment on a proposed change b) guides and other vouched people can comment and 'vote' c) the area-guide can signify yea/nay and have the change automatically moved to an appropriate holding area d) an accepted change gets the update number attached for tracking Probably possible with swiki or seaside?
tim
Yes but there has been quite a number of 'last minute important fixes' traffic, not least a few fixes I consider important. I can't find anything that lets me know if those fixes are queued up anywhere - not even with the magical 'look at internal server' patch. Without the sqfixes page and its brethren I'm stuck. Terribly vexing.
The use of the internal update stream seems to be a real weakness in the current release cycle. In the good ol' days (you know, when men were REAL men and women were REAL women and little furballs from aldebaran were REAL little furballs from aldebaran) SqC was testing everything that went into the internal stream almost immediately (which meant that we usually updated at least once a day if not more often). So the internal update stream allowed us to review everything that's "hot off the press" and in quite a number of situations we found (some really horrible) problems before they went out to the general public and at times fixed them "under the hoods" (such as by rewriting files directly on the server, heh, heh ;-)
However, if nobody who is both willing to test hot stuff as well as having the authority to fix any problems right away is sitting on top of the internal updates it seems utterly pointless to even have it. So if you have to 'look at the internal server' or any such thing then it means that the current release cycle is severely broken. The internal updates were always intended to be tested immediately and not to rot until they're forgotten.
I don't know how many people (if any) use the internal update stream (I no longer do because I no longer have authority to post any updates) but if there aren't a few experienced people who use it daily then I would recommend getting rid of it altogether. After all, it's up to people to decide when they wish to update and there is always some risk that updates (in particular on alpha/beta streams) could break something. But on the other hand, given the lengthy discussion each update seems to receive before it ever gets promoted, the chances for breaking anything in truly horrible ways seem to be pretty small.
So my bottom line recommendation is: Get rid of this darn "internal" update stream if you don't use it! Rather I would suggest to require submissions to identify changes that interact with the system in critical ways (such as any rewrite of deep system level stuff). Then require a minimum number of EXPERIENCED testers (and not just eyeballs which all claim that "yes it files into a virgin image just fine") to look at and try this stuff in real life situations to identify possible problems. And leave it up to the people submitting the change to identify those testers - after all there's either a demand for the change so it ought to be simple to find them or else that person has an interest in this change so he or she ought to be able to convince a few people to test it.
Cheers, - Andreas
So my bottom line recommendation is: Get rid of this darn "internal" update stream if you don't use it!
I'd pretty much agree with that BUT I think there is a possible sensible use for it. If it were used as a last staging post for changes (after the review etc you referred to) that were about to be released, then it provides a last chance to test it with _really_ everything else it has to live with. Unit testing is a good thing and must be done but we've seen plenty of problems with unexpected interactions (what a surprise).
tim
Tim,
I'd pretty much agree with that BUT I think there is a possible sensible use for it.
There are actually lots of sensible uses for an internal update stream. But you have to use it! And, unless I am totally mistaken your message claimed that you were using some magic "look at internal server patch" which means only one thing - you don't use it.
The point here is not about whether an "internal" update stream _can_ be useful. The point is that in order to be useful it has to be _put_ to use, e.g., someone has to actually run the stuff that's in it. If noone does, then it's only getting into the way of both, testing and the release process in general (e.g., "is this update included?").
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de appears to have written:
The point here is not about whether an "internal" update stream _can_ be useful. The point is that in order to be useful it has to be _put_ to use, e.g., someone has to actually run the stuff that's in it. If noone does, then it's only getting into the way of both, testing and the release process in general (e.g., "is this update included?").
Exactly so. My problem is that I don't see anything in the internal stream and without an uptodate sqfixes page (or suitable substitute) it's hard to keep track of what to look into. I haven't been keeping every email that could possibly relate to changes; perhaps I should.
I think we just need to get some organisation into place. Now that assorted holiday type distractions are over maybe we can do so?
tim
Tim Rowledge tim@sumeru.stanford.edu wrote:
"Andreas Raab" andreas.raab@gmx.de appears to have written:
The point here is not about whether an "internal" update stream _can_ be useful. The point is that in order to be useful it has to be _put_ to use, e.g., someone has to actually run the stuff that's in it. If noone does, then it's only getting into the way of both, testing and the release process in general (e.g., "is this update included?").
Exactly so. My problem is that I don't see anything in the internal stream and without an uptodate sqfixes page (or suitable substitute) it's hard to keep track of what to look into. I haven't been keeping every email that could possibly relate to changes; perhaps I should.
I think we just need to get some organisation into place. Now that assorted holiday type distractions are over maybe we can do so?
Yes, agree with Andreas on his points. I am not sure what Tim means by "...I don't see anything in the internal stream..." because I have seen stuff in there before it went out, but whatever.
The REAL solution is of course to follow up on the proposed tool that Doug and I and Luciano have been discussing - a sort of Harvesting tool using some similar mechanisms as SM does but in a package centric way.
The idea is that harvesters have the ability to review/comment and move fixes forward in a kindof "assembly line" fashion into different stages and finally out into an update stream. This "assembly line" will be viewable by all (and kept up to date similarly to SM) so there will be no doubt where a FIX has gone and what status it has.
And further we have been thinking of:
1. Adding Monticello to the mix like a "workbench" so that a FIX can be "lifted" temporarily off the assembly line onto the workbench (a Monticello shared repo) so that multiple developers can work on it "at the same time" banging it into shape and then when it looks good lift it back onto the assembly line.
2. When FIXes have gotten good reviews etc and passed whatever criteria/stages we want to have it moves into the final "release queue" which batchwise is published onto the update stream(s). Note the "s" here which signifies that this tool should be "package aware". Perhaps by having multiple assembly lines, a line for every package that wants it, and/or possibly multiple release queues (for different packages)
Anyway, that is the gist of it. The idea is to reuse the architecture of SM for much of it (but this is a completely separate tool of course), add a Morphic UI of course and then off we go.
IMHO anyone can start working on this - I am pressed for time but can surely help out regarding the SM base. Doug is good on the UI side and also has the knowledge about the "Harvesting needs". Luciano was very interested to help out and has looked into the SM code.
Furthermore Doug has written this on the subject - he is the man in charge (sorry for blabbering):
http://swiki.squeakfoundation.org/squeakfoundation/86
regards, Göran
Andreas Raab wrote:
I'd pretty much agree with that BUT I think there is a possible sensible use for it.
There are actually lots of sensible uses for an internal update stream. But you have to use it! And, unless I am totally mistaken your message claimed that you were using some magic "look at internal server patch" which means only one thing - you don't use it.
The point here is not about whether an "internal" update stream _can_ be useful. The point is that in order to be useful it has to be _put_ to use, e.g., someone has to actually run the stuff that's in it. If noone does, then it's only getting into the way of both, testing and the release process in general (e.g., "is this update included?").
I don't have a strong opinion yet on whether we should keep the internal update stream. I actually have been using it somewhat. Right now, the Guides and SqC have access to it. But I agree that it's not getting nearly as much use as when SqC used it full-time, and it may become less necessary if we have stricter criteria about what gets added to the update stream.
Maybe we should keep the internal update stream for a while in 3.5alpha, at least, to see if it's useful or not.
(By the way, Scott just posted the various "fixes before 3.4gamma" updates to the internal update stream today.)
- Doug
Doug Way dway@riskmetrics.com said:
(By the way, Scott just posted the various "fixes before 3.4gamma" updates to the internal update stream today.)
I don't know what this internal update stream thingy is or who's output port you have to kiss in order to get access to it, but I think (exactly for these reasons) that it should go.
A much better alternative would be to have a marker file on the regular update stream indicate the latest 'safe' update (for some value of safe). Cool bl33ding edge hackers could ignore the marker, while regular users (using 'Update from server') would have their updates stop at the number indicated in the marker file.
Then everyone could decide for themselves how bleeding edge they'd like to be, and how much they want to contribute to pre-alpha testing.
The absolutely most vital thing if Squeak's to be a success under the new model of governance is to make it as transparent as possible. No hidden areas for some 'privileged' people, the only privileges we should hand out is decision privileges, not information privileges.
cg@cdegroot.com (Cees de Groot) wrote:
Doug Way dway@riskmetrics.com said:
(By the way, Scott just posted the various "fixes before 3.4gamma" updates to the internal update stream today.)
I don't know what this internal update stream thingy is or who's output port you have to kiss in order to get access to it, but I think (exactly for these reasons) that it should go.
:-) I agree Cees but a simple explanation might be in order here - it is a remnant that we decided to keep until 3.4 is out the door just because we (or at least I) didn't want to start banging on something and thus disrupting the "quick" release of 3.4. Since Scott is doing most of the legwork currently it was easy to let him continue his work as he is used to.
But we all agree that there should be no "secret" privileged place for updates of course.
A much better alternative would be to have a marker file on the regular update stream indicate the latest 'safe' update (for some value of safe). Cool bl33ding edge hackers could ignore the marker, while regular users (using 'Update from server') would have their updates stop at the number indicated in the marker file.
Then everyone could decide for themselves how bleeding edge they'd like to be, and how much they want to contribute to pre-alpha testing.
The absolutely most vital thing if Squeak's to be a success under the new model of governance is to make it as transparent as possible. No hidden areas for some 'privileged' people, the only privileges we should hand out is decision privileges, not information privileges.
Again I wholeheartedly agree and this is one of the things I really tried to push in the mission statement. That is also one of the reasons we keep all discussions on this list and not off list. Consider this a remnant that will go away very soon.
I think a focused effort to bring about the new Harvesting tool would be the best way to proceed. Hacking the update mechanism just seems like a "hack" that will not give us anything really. We are just about (any day) to open 3.5alpha and IMHO alpha means on the bl33ding goddamn hold-on-it's-gonna-blow edge and when we have that stream open I think we can simply ditch the "secret" internal stream and then just get the new tool out the door before we try to turn 3.5 into beta (at which point such a tool will be much more needed).
Please guys, lets use the new alpha stream as ALPHA is meant to - push stuff into it and let the ALPHA-testers take the hit. We need to let FIXes go into it with much less scrutiny in order to keep up. IMHO, the only scrutiny we really need to do is to verify that it is indeed FIXes and not additions to the bloating image.
regards, Göran
Tim Rowledge wrote:
goran.hultgren@bluefish.se is claimed by the authorities to have written:
What isn't good is that I can't quite work out what we've decided will be in the gamma release, nor _how_ we've decided it. Perhaps it's just
I think we decided it on this list and that it includes exactly what is in the beta! :-) Doug has taken quite some time/effort to post on the updates we wanted to include before going into beta/gamma of 3.4 and the basic intention behind it all was (also discussed on the list) to simply get 3.4 out he door since it includes all the 3.3 alpha stuff (without Modules of course) and more and we wanted to get a "quick release" so that we can take a breath and start the real work in 3.5.
Yes but there has been quite a number of 'last minute important fixes' traffic, not least a few fixes I consider important. I can't find anything that lets me know if those fixes are queued up anywhere - not even with the magical 'look at internal server' patch. Without the sqfixes page and its brethren I'm stuck. Terribly vexing.
As Göran said, we more or less agreed to handle the 3.4 fixes on an "ad-hoc" basis, meaning they would just be discussed on this list. (At least, there were no strenuous objections. :-) ) See http://lists.squeakfoundation.org/pipermail/squeakfoundation/2002-November/0... (hm, there was more discussion about this somewhere...)
This was assuming 3.4 would be wrapped up relatively soon, then with 3.5alpha, we'd work on a better process/tools.
I posted some thoughts on possibilities for better tools here a little while ago:
http://swiki.squeakfoundation.org/squeakfoundation/86
I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc. I guess we could still use the term "harvesting" to cover all base-Squeak development? And we also have to consider package-level harvesting as the image gets split up into packages.
I'd suggest we need to caucus on the issue of some tools to help us handle fixes and changes more effectively in preparation for the onslaught of brilliant ideas that is likely to hit us like a tsunami for 3.5
True, we run the risk of being overwhelmed here if we're not careful. :)
First suggestion I'd like to make is that the sqfixes page be changed to make use of more targetted editing capabilities of swiki; rather than having to edit the entire chunk of code, it is actually possible to have an edit dooberry for each individual item.
Second nice thing would be some interface so that a) 'ordinary' people can comment on a proposed change b) guides and other vouched people can comment and 'vote' c) the area-guide can signify yea/nay and have the change automatically moved to an appropriate holding area d) an accepted change gets the update number attached for tracking Probably possible with swiki or seaside?
This interface sounds similar to what I had in mind.
Göran mentioned at one point that he and Luciano N. were looking at using a modified SqueakMap as the infrastructure for this, which I think might work. There are other ways it could be done. I'm not sure we want to stick with the Swiki method; it may be too limiting.
In any case, we should get working on this, since 3.5alpha will be opening soon. Perhaps Luciano could get started with something based on SqueakMap 1.05, if we want to use SqueakMap as a base for this tool. (We definitely don't need to wait around for SM 1.1 for this.) If we have a basic submitting/annotating/voting tool working, we can use that as a starting point for refinement of the process, which can be discussed on this list...
If others want to actively help out with getting the basic tool going, feel free to volunteer here.
- Doug
Doug Way dway@riskmetrics.com said:
I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc. I guess we could still use the term "harvesting" to cover all base-Squeak development? And we also have to consider package-level harvesting as the image gets split up into packages.
'Harvesting' implies 'adding'. As far as I'm concerned, it should be a 'stripping' process for the time to come, and then an 'updating/bugfixing' process. So even if the infrastructure stays the same, maybe it should be renamed post-3.5 to something which implies less bloat-orientation ;-).
OBTW: I'm going to try to port Squeak to Posix (command line, that is). I'll probably fail due to lack of time, but in the light of the whole modular Squeak discussion it does act as a sort of minimum Squeak reference point - just the VM and a minimal RTL. How small should the smallest module be? This small? (which would make a 'core Squeak' distribution already a collection of modules - 'kernel Squeak' plus user interface, primitives for sound/multimedia, etcetera). Not really relevant to the current discussion (except maybe for the infrastructure needed), it just popped up :)
cg@cdegroot.com (Cees de Groot) wrote:
Doug Way dway@riskmetrics.com said:
I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc. I guess we could still use the term "harvesting" to cover all base-Squeak development? And we also have to consider package-level harvesting as the image gets split up into packages.
'Harvesting' implies 'adding'. As far as I'm concerned, it should be a 'stripping' process for the time to come, and then an 'updating/bugfixing' process. So even if the infrastructure stays the same, maybe it should be renamed post-3.5 to something which implies less bloat-orientation ;-).
Well, the new tool will be package aware so it will not only handle FIXes to the image. Thus harvesting is still an ok term IMHO. But I agree of course about what you mean.
OBTW: I'm going to try to port Squeak to Posix (command line, that is). I'll probably fail due to lack of time, but in the light of the whole modular Squeak discussion it does act as a sort of minimum Squeak reference point - just the VM and a minimal RTL. How small should the smallest module be? This small? (which would make a 'core Squeak' distribution already a collection of modules - 'kernel Squeak' plus user interface, primitives for sound/multimedia, etcetera). Not really relevant to the current discussion (except maybe for the infrastructure needed), it just popped up :)
Talk with Andreas and Dan - they have already done stuff in this direction if I am not mistaken. On the other hand I haven't heard anything about their progress so perhaps it has been abandoned. Dan said he would post his minimal image but I never saw it, sigh...
regards, Göran
I've just been trying to review the process for harvesting and reveiwing fixes. It all seems a bit confused right now. There's the sqfixes page(s)on http://209.143.91.36/super/415 and various pages pointed to from there but much is out of date. For a start I can hardly bundle up stuff I've reviewed and email it to SqC anymore can I?
Perhaps I've missed stuff whilst I had my head down trying to update the VMMaker codebase? Given some fix or enh or whatever that I've reveiwed and would like to promote, what is the current best process?
tim
Doug Way dway@riskmetrics.com wrote: [SNIP]
I posted some thoughts on possibilities for better tools here a little while ago:
Right. Just posted on the other thread before reading this. Duh.
I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc. I guess we could still use the term "harvesting" to cover all base-Squeak development? And we also have to consider package-level harvesting as the image gets split up into packages.
Agree. Harvesting is a nice word. And package-level harvesting is "of course" the way to go.
[SNIP]
Göran mentioned at one point that he and Luciano N. were looking at using a modified SqueakMap as the infrastructure for this, which I think might work. There are other ways it could be done. I'm not sure we want to stick with the Swiki method; it may be too limiting.
Agree.
In any case, we should get working on this, since 3.5alpha will be opening soon. Perhaps Luciano could get started with something based on SqueakMap 1.05, if we want to use SqueakMap as a base for this tool. (We definitely don't need to wait around for SM 1.1 for this.)
Right, no need for SM 1.1 for this. There are no changes planned in the underlying architecture.
If we have a basic submitting/annotating/voting tool working, we can use that as a starting point for refinement of the process, which can be discussed on this list...
If others want to actively help out with getting the basic tool going, feel free to volunteer here.
I will help out any way I can without actually doing it all myself. :-) I think this is a good plan - just a proposal for he/she who picks up the ball:
1. Look at SM, the code is pretty simple. Change it to suit the new domain. Use it to maintain the shared meta data about the assembly lines/FIXes etc.
2. Add a simple HTTP upload facility so that people can submit changesets into the assembly line easily from within the changesorter tools. I have code already for an HTTP upload server so don't write it again - I can whip up a changeset with it.
3. Pick one of the SM UIs and rewrite it to suit this tool. These new tools are pretty lean and easy to hack (instead of digging through the endless cruft of Browser and friends once again).
4. Let the tool use simple a simple HTTP protocol to issue "write operations" to the server. In a KISS fashion I would simply issue "Smalltalk evals" over HTTP instead of mucking about with SOAP etc. But that's just me - I like simple things with very little dependencies on other stuff. Remember that we are talking about a core tool for Squeak - it shouldn't require too much "other stuff" to work.
Well, there you go. :-)
rgards, Göran
squeakfoundation@lists.squeakfoundation.org
-
Andreas Raab -
cg＠cdegroot.com -
Doug Way -
goran.hultgren＠bluefish.se -
Tim Rowledge