Here is the proposal I sent to the Squeak board. ---------------- The Squeak 3.10 release team is going to focus on developing a simple, visible and reliable process for creating new releases.
The alpha 3.10 release will have an image and a set of core packages. Each will have a test suite, and all tests in the test suites will pass when any subset of the packages is loaded into the image. Each subsequent version will continue to keep the existing packages working.
We expect the alpha release and all later releases to be usable. We want people to feel comfortable using the latest version so that 3.10 will be heavily used long before the final version and most bugs will be discovered.
Our plan is to have the alpha release by the end of January and to accept major changes for the next three months, i.e. til the end of April. "Major changes" will include moving code from the image into packages and making new core packages. We are not expecting any major new features in the image. The last month will be only bug fixes, and a final version of 3.10 will be the end of May.
The main focus will be on developing a good process for creating releases. So, we expect to experiment with the process. Ideally, the final process would be so easy to follow that it would be easy to be in charge of producing a release.
The current process plan is that all requests for change would go through Mantis. Each bug fix would have a test that shows the bug and that shows that it is fixed. The release team would periodically (once or twice a week, perhaps every day) go through Mantis, test each change to make sure it doesn't break anything, and commit them to the current release.
The releases would be distributed in several ways. There will be a "package universe" of all the core packages, and perhaps one of non-core packages, as well. There will be an update server so that people do not have to load new images to stay up to date. There will be a Montecello repository of all the changes so that everything we do will be repeatable. We will try to make it easy for people to use the release that is under active development.
Current members of the release team are Ralph Johnson and Edgar J. De Cleeene. -------------- Reading it again, I can think of some comments.
The main one is that this is explaining what the Squeak team will do, which is to develop a process for making releases and shrinking the image. Part of the process is making it easy for other people to fix bugs and add features. I am not opposed to adding features! You could think that from this proposal. I just think that adding features should be what everybody does, not just the release team.
As part of fixing the process, a large part of my job will be getting people to participate. I expect that the social engineering will be more work than the software engineering. The software engineering is, in my opinion, very standard and routine, though I am sure I will get some argument about that. The social engineering will require more creativity.
-Ralph
On Thu, 23 Nov 2006 13:06:00 +0100, Ralph Johnson wrote:
Here is the proposal I sent to the Squeak board.
The Squeak 3.10 release team is going to focus on developing a simple, visible and reliable process for creating new releases.
The alpha 3.10 release will have an image and a set of core packages.
...
Current members of the release team are Ralph Johnson and Edgar J. De Cleeene.
Ralph and Edgar,
I appreciate your initiative and would like to know more about what you consider to be a core package and, what is the resulting image when you subtract all the core packages. Do I have to understand this being based on a kernel image and, what about Pavel's kernel image?
The current process plan is that all requests for change would go through Mantis.
...
There will be a Montecello repository of all the changes so that everything we do will be repeatable.
This has to be applauded for it will create records for Squeak's history.
Each bug fix would have a test that shows the bug and that shows that it is fixed.
What about non-bugs, like for example performance issues. Or do you count them to the bug category.
I'm just curious and try to find out what support you may need.
/Klaus
On 11/23/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
I appreciate your initiative and would like to know more about what you consider to be a core package and, what is the resulting image when you subtract all the core packages. Do I have to understand this being based on a kernel image and, what about Pavel's kernel image?
Are you asking "what are we going to subtract"? I do not know. I would like to see anything subtracted that can then be added back in. Lots of people are interested in splitting eToys into a separate package. I don't think anybody will argue with this as long as it can be loaded back in. However, I do not think of that as necessarily being a release team responsibility. Pavel Krivanek is working on eToys and seems to be doing a good job. In general, we are going to focus on the process of transforming the image in such a way that other programs are affected as little as possible. We'll emphasize supporting other people making transformations and not plan to do it all ourselves.
If I made a list of things that should be separate packages, it would look a lot like other people's lists. I want the release team to focus on the *process* of splitting the image into packages, not the particular set of packages. You can't have a good process unless you practice it constantly, so we will make packages as well as helping other people make packages. My guess is that other people will do the high-impact, high visibility packages, and I will do the boring ones. Edgar is working with Pavel on eToys and Morphic, but that is too big a project for me right now.
Each bug fix would have a test that shows the bug and that shows that it is fixed.
What about non-bugs, like for example performance issues. Or do you count them to the bug category.
New changes shouldn't break any of the existing tests. I suppose that some of them will come with their own tests, and some won't. It would be good for Squeak to have more tests, but we are not going to be hard on people about this.
-Ralph
Ralph Johnson skrev:
On 11/23/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
I appreciate your initiative and would like to know more about what you consider to be a core package and, what is the resulting image when you subtract all the core packages. Do I have to understand this being based on a kernel image and, what about Pavel's kernel image?
Are you asking "what are we going to subtract"? I do not know. I would like to see anything subtracted that can then be added back in. Lots of people are interested in splitting eToys into a separate package. I don't think anybody will argue with this as long as it can be loaded back in. However, I do not think of that as necessarily being a release team responsibility. Pavel Krivanek is working on eToys and seems to be doing a good job. In general, we are going to focus on the process of transforming the image in such a way that other programs are affected as little as possible. We'll emphasize supporting other people making transformations and not plan to do it all ourselves.
If I made a list of things that should be separate packages, it would look a lot like other people's lists. I want the release team to focus on the *process* of splitting the image into packages, not the particular set of packages. You can't have a good process unless you practice it constantly, so we will make packages as well as helping other people make packages. My guess is that other people will do the high-impact, high visibility packages, and I will do the boring ones. Edgar is working with Pavel on eToys and Morphic, but that is too big a project for me right now.
Each bug fix would have a test that shows the bug and that shows that it is fixed.
What about non-bugs, like for example performance issues. Or do you count them to the bug category.
New changes shouldn't break any of the existing tests. I suppose that some of them will come with their own tests, and some won't. It would be good for Squeak to have more tests, but we are not going to be hard on people about this.
-Ralph
I have a question about tools. There are some issues with Monticello and refactoring where methods moved between packages disappears. Another issue is load ordering, Monticello does not do atomic loading. A third is dependencies between packages. These issues caused a lot of headache for the 3.9 guys. How should we approach these issues ?
Karl
On 11/24/06, karl karl.ramberg@chello.se wrote:
I have a question about tools. There are some issues with Monticello and refactoring where methods moved between packages disappears. Another issue is load ordering, Monticello does not do atomic loading. A third is dependencies between packages. These issues caused a lot of headache for the 3.9 guys. How should we approach these issues ?
I've only used MC for small projects, so am not sure about the problems with large projects. If MC loses methods then that is a bug. Perhaps we will go to MC2. I don't know how soon MC2 will be ready or whether it will fix the problems that the 3.9 team had with it. I'm thinking about using Package Universe as a way to make Squeak easier for novice Squeakers. It handles dependencies well. Based on what I heard from the 3.9 team, I am not planning to rely on MC for everything.
For a decade or so, I built large systems using only change files. So, we can always fall back on them if necessary. But I've also used Envy and Store and so would prefer higher-level tools.
The reason I say that my goal is to develop a process is because I am not sure what the process should be. We'll try some things and talk a lot about it and I am sure we can figure something out.
What do you mean that MC doesn't do atomic loading? It only loads one package at a time, doesn't it? Do you mean that it can die half-way through loading a package, with some classes loaded and some not? I know that normally a MC package does not specify dependencies. I think that is the purpose of the Configuration.
-Ralph
I put forward some work I am doing as a kind of example scenario, how would the process handle this one, kind of thing.
What do you mean that MC doesn't do atomic loading? It only loads one package at a time, doesn't it? Do you mean that it can die half-way through loading a package, with some classes loaded and some not? I know that normally a MC
I am looking at pulling together some recent tweaks and bug fixes to the DateAndTime code. (see mantis 474 which doesnt have my final code as yet , see below). As you highlight I don't currently know the process for publishing these changes once they work. Nor do I have the tools with which to achieve testing, packaging or distribution.
First Problem ref. your comment about Atomic loading (which I have heard rumour MC2 does support! yay!)
Atomic loading might help, since loading in code that modifies DateAndTime-#now, really upsets the code that is loading and time stamping the newly installed methods as they are compiled. As soon as someone calls #now, before the class is fully loaded and importantly before the class has been initialized we crash and burn.
As I understand it atomic loading ensures that all methods are loaded and classes initialised and actually ready to use before anyone 'out there' in the system actually tries to use them. The new code is 'switched in' in one atomic operation, which will either work or break things. The non-atomic situation frequently causes problems in the part-loaded, not quite initialised state. Fixing fileIn with a fileIn, or indeed tweaking the compiler is usually a no-no.
Second Problem, I am struggling to work out how to test my new code fully.
1. It turns out that the millisecondClockValue supplied by the vm, is one of those SmallInteger things which will roll over every once in a while. One needs to set up the scenario just before and after the roll over in order to see that everything is handled smoothly.
2. I have organised this implementation around a call #milliSecondsSinceMidnight, and it is necessary to test that the transition from 23:59.59 to 00:00.00 also goes smoothly.
So within my test environment I have no control over the vm's millisecondClock. Secondly all of the interesting things, like timing offsets are stored in Class variables so my test code can't really mess with them. The best I can probably manage is to test the 'algorithm' and hope for the best. Any ideas?
Without MC2, I was expecting to shrink KernelImage's Chronology to a bare minimum, load an implementation with safe methods only, get everything initialised and then load the unsafe methods in in a hand crafted change set.
any further ideas would be appreciated
Keith
Send instant messages to your online friends http://uk.messenger.yahoo.com
On 11/24/06, Keith Hodges keith_hodges@yahoo.co.uk wrote:
I put forward some work I am doing as a kind of example scenario, how would the process handle this one, kind of thing.
I am looking at pulling together some recent tweaks and bug fixes to the DateAndTime code. (see mantis 474 which doesnt have my final code as yet , see below).
Atomic loading might help, since loading in code that modifies DateAndTime-#now, really upsets the code that is loading and time stamping the newly installed methods as they are compiled. As soon as someone calls #now, before the class is fully loaded and importantly before the class has been initialized we crash and burn.
i don't know the answer to this, but I will guess.
I am far from a Monticello expert, but I have been looking at the code. It looks to me that class PackageLoader could be changed to load atomically. Basically, instead of making one pass through MCDefinitions (such as MCMethodDefinition, MCCLassDefinition and MCScript) and loading each one, the PackageLoader should first make a pass doing a preload and then a pass doing a load. Classes will be loaded during the preload and methods will be compiled during the preload, but actually installed during the load.This would mean that you wouldn't run the compiler during the actualy loading of methods. Something similar would have to be done for unloading.
Do people who know more about MC than I do think this would work?
Second Problem, I am struggling to work out how to test my new code fully.
No code is every tested fully. The question is whether it is tested enough. Perhaps you should settle for less complete tests.
- It turns out that the millisecondClockValue supplied by the vm, is
one of those SmallInteger things which will roll over every once in a while. One needs to set up the scenario just before and after the roll over in order to see that everything is handled smoothly.
Mock up the millisecondClockValue from the VM. Make a little "clock" object that you can replace with a mock object for testing.
- I have organised this implementation around a call
#milliSecondsSinceMidnight, and it is necessary to test that the transition from 23:59.59 to 00:00.00 also goes smoothly.
So within my test environment I have no control over the vm's millisecondClock. Secondly all of the interesting things, like timing offsets are stored in Class variables so my test code can't really mess with them. The best I can probably manage is to test the 'algorithm' and hope for the best. Any ideas?
Mock these as well. Redesign the class so it is easy to test.
Or just have easier tests.
-Ralph
On Nov 24, 2006, at 9:32 PM, Ralph Johnson wrote:
I am far from a Monticello expert, but I have been looking at the code. It looks to me that class PackageLoader could be changed to load atomically. Basically, instead of making one pass through MCDefinitions (such as MCMethodDefinition, MCCLassDefinition and MCScript) and loading each one, the PackageLoader should first make a pass doing a preload and then a pass doing a load. Classes will be loaded during the preload and methods will be compiled during the preload, but actually installed during the load.This would mean that you wouldn't run the compiler during the actualy loading of methods. Something similar would have to be done for unloading.
Do people who know more about MC than I do think this would work?
Yeah, sounds reasonable.
For MC2, I created a package called SystemEditor that uses roughly the same approach. It presents an "editing" interface with the same protocol as the real system. I'm sure it's not quite identical, but it's close enough that MC2 can have atomic loading turned on or off with a one-line change.
It probably wouldn't be much work to make MC1 load definitions through SystemEditor rather than SystemDictionary. More work would have to go into SystemEditor to make it solid enough for production use, but it's still probably less work than starting from scratch.
Colin
Here's a class initialization scheme that worked well with in the past:
1) The classes of a package are loaded in any sequence (but not initialized!) 2) Class initialization is done by a kernel method that initializes ALL classes as follows: 2a) First, send #initialize to ALL classes that have it implemented. someClass class>>initialize initializes constants etc. It is local to the class, only using kernel classes such as String, Integer, ... 2b) Second, send e.g., #squeakInitialize to ALL classes that have it implemented. someClass class>>squeakInitialize sets up required links. It can reference any class, since all classes have been loaded. 2c) If #squeakInitialize can only be run in a certain sequence, the classes are too fragile and should be redesigned. 3) Some library classes did not tolerate repeated initializations. We regarded that as a weakness and fixed the offending classes to enable the above scheme.
Cheers --Trygve
On 25.11.2006 06:32, Ralph Johnson wrote:
On 11/24/06, Keith Hodges keith_hodges@yahoo.co.uk wrote:
I put forward some work I am doing as a kind of example scenario, how would the process handle this one, kind of thing.
I am looking at pulling together some recent tweaks and bug fixes to the DateAndTime code. (see mantis 474 which doesnt have my final code as yet , see below).
Atomic loading might help, since loading in code that modifies DateAndTime-#now, really upsets the code that is loading and time stamping the newly installed methods as they are compiled. As soon as someone calls #now, before the class is fully loaded and importantly before the class has been initialized we crash and burn.
i don't know the answer to this, but I will guess.
I am far from a Monticello expert, but I have been looking at the code. It looks to me that class PackageLoader could be changed to load atomically. Basically, instead of making one pass through MCDefinitions (such as MCMethodDefinition, MCCLassDefinition and MCScript) and loading each one, the PackageLoader should first make a pass doing a preload and then a pass doing a load. Classes will be loaded during the preload and methods will be compiled during the preload, but actually installed during the load.This would mean that you wouldn't run the compiler during the actualy loading of methods. Something similar would have to be done for unloading.
Do people who know more about MC than I do think this would work?
Second Problem, I am struggling to work out how to test my new code fully.
No code is every tested fully. The question is whether it is tested enough. Perhaps you should settle for less complete tests.
- It turns out that the millisecondClockValue supplied by the vm, is
one of those SmallInteger things which will roll over every once in a while. One needs to set up the scenario just before and after the roll over in order to see that everything is handled smoothly.
Mock up the millisecondClockValue from the VM. Make a little "clock" object that you can replace with a mock object for testing.
- I have organised this implementation around a call
#milliSecondsSinceMidnight, and it is necessary to test that the transition from 23:59.59 to 00:00.00 also goes smoothly.
So within my test environment I have no control over the vm's millisecondClock. Secondly all of the interesting things, like timing offsets are stored in Class variables so my test code can't really mess with them. The best I can probably manage is to test the 'algorithm' and hope for the best. Any ideas?
Mock these as well. Redesign the class so it is easy to test.
Or just have easier tests.
-Ralph
Keith Hodges keith_hodges@yahoo.co.uk writes:
Second Problem, I am struggling to work out how to test my new code fully.
- It turns out that the millisecondClockValue supplied by the vm, is
one of those SmallInteger things which will roll over every once in a while. One needs to set up the scenario just before and after the roll over in order to see that everything is handled smoothly.
- I have organised this implementation around a call
#milliSecondsSinceMidnight, and it is necessary to test that the transition from 23:59.59 to 00:00.00 also goes smoothly.
So within my test environment I have no control over the vm's millisecondClock. Secondly all of the interesting things, like timing offsets are stored in Class variables so my test code can't really mess with them. The best I can probably manage is to test the 'algorithm' and hope for the best. Any ideas?
Tough one!
You could modify the code to make this part replaceable. If it is just a few methods in question, you could give them an extra argument which is the technique to use for reading the system clock. By default they could use millisecondClock, but your tests could replace them with a mock object that returns repeatable, tricky clock values.
-Lex
Ralph Johnson wrote,
If I made a list of things that should be separate packages, it would look a lot like other people's lists. I want the release team to focus on the *process* of splitting the image into packages, not the particular set of packages. You can't have a good process unless you practice it constantly, so we will make packages as well as helping other people make packages.
This sounds like music to my ears!!
Thanks for tackling this very important task. It's great that someone with your reputation is doing it. I am sure this will attract a lot of other people.
Cheers, Francisco
Dear Ralph,
I think movments like the one you are exposing here adds value to the whole Squeak as project. Also adds value to all Smalltlak as a consequence.
I'm pretty sure that the projects that will emerge, based on Squeak versions like that, eventually will gain a lot more value just because of that. Very healthy initiative.
If the objetives can be archieved, it can be useful as support of a wisely defined marketing strategy campaing (just for reference: http://www.4hb.com/0107flmarketingcampaign.html).
Cheers,
Sebastian Sastre
ssastre@seaswork.com.ar Seaswork Special Software Solutions
Este mensaje y sus adjuntos son confidenciales y de uso exclusivo para el usuario a quien esta dirigido. Puede contener información amparada por el secreto profesional. Si Ud. no es el destinatario especificado no debe copiar, enviar o utilizar ninguna parte del mismo y/o de sus adjuntos por ningún medio tecnológico. Las opiniones vertidas son responsabilidad del autor y no son emitidas ni avaladas por SEASWORK a menos que se indique claramente lo contrario y que la identidad y autoridad del autor, para comprometer a nuestra empresa, puedan ser verificados. No se garantiza la integridad de los mensajes enviados por e-mail ni que los mismos sean enviados en termino, o que no contengan errores o virus. El emisor no aceptara responsabilidad por los errores, modificaciones u omisiones que resulten en el mensaje, bajo la hipótesis de que pudo ser modificado.
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ralph Johnson Sent: Thursday, November 23, 2006 10:06 AM To: The general-purpose Squeak developers list Subject: release team proposal
Here is the proposal I sent to the Squeak board.
The Squeak 3.10 release team is going to focus on developing a simple, visible and reliable process for creating new releases.
The alpha 3.10 release will have an image and a set of core packages. Each will have a test suite, and all tests in the test suites will pass when any subset of the packages is loaded into the image. Each subsequent version will continue to keep the existing packages working.
We expect the alpha release and all later releases to be usable. We want people to feel comfortable using the latest version so that 3.10 will be heavily used long before the final version and most bugs will be discovered.
Our plan is to have the alpha release by the end of January and to accept major changes for the next three months, i.e. til the end of April. "Major changes" will include moving code from the image into packages and making new core packages. We are not expecting any major new features in the image. The last month will be only bug fixes, and a final version of 3.10 will be the end of May.
The main focus will be on developing a good process for creating releases. So, we expect to experiment with the process. Ideally, the final process would be so easy to follow that it would be easy to be in charge of producing a release.
The current process plan is that all requests for change would go through Mantis. Each bug fix would have a test that shows the bug and that shows that it is fixed. The release team would periodically (once or twice a week, perhaps every day) go through Mantis, test each change to make sure it doesn't break anything, and commit them to the current release.
The releases would be distributed in several ways. There will be a "package universe" of all the core packages, and perhaps one of non-core packages, as well. There will be an update server so that people do not have to load new images to stay up to date. There will be a Montecello repository of all the changes so that everything we do will be repeatable. We will try to make it easy for people to use the release that is under active development.
Current members of the release team are Ralph Johnson and Edgar J. De Cleeene.
Reading it again, I can think of some comments.
The main one is that this is explaining what the Squeak team will do, which is to develop a process for making releases and shrinking the image. Part of the process is making it easy for other people to fix bugs and add features. I am not opposed to adding features! You could think that from this proposal. I just think that adding features should be what everybody does, not just the release team.
As part of fixing the process, a large part of my job will be getting people to participate. I expect that the social engineering will be more work than the software engineering. The software engineering is, in my opinion, very standard and routine, though I am sure I will get some argument about that. The social engineering will require more creativity.
-Ralph
This sounds exactly right. Are you going to use Pavel's work? It sounds like he is doing a lot of what is talked about here.
From: "Ralph Johnson" johnson@cs.uiuc.edu Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: release team proposal Date: Thu, 23 Nov 2006 06:06:00 -0600
Here is the proposal I sent to the Squeak board.
The Squeak 3.10 release team is going to focus on developing a simple, visible and reliable process for creating new releases.
The alpha 3.10 release will have an image and a set of core packages. Each will have a test suite, and all tests in the test suites will pass when any subset of the packages is loaded into the image. Each subsequent version will continue to keep the existing packages working.
We expect the alpha release and all later releases to be usable. We want people to feel comfortable using the latest version so that 3.10 will be heavily used long before the final version and most bugs will be discovered.
Our plan is to have the alpha release by the end of January and to accept major changes for the next three months, i.e. til the end of April. "Major changes" will include moving code from the image into packages and making new core packages. We are not expecting any major new features in the image. The last month will be only bug fixes, and a final version of 3.10 will be the end of May.
The main focus will be on developing a good process for creating releases. So, we expect to experiment with the process. Ideally, the final process would be so easy to follow that it would be easy to be in charge of producing a release.
The current process plan is that all requests for change would go through Mantis. Each bug fix would have a test that shows the bug and that shows that it is fixed. The release team would periodically (once or twice a week, perhaps every day) go through Mantis, test each change to make sure it doesn't break anything, and commit them to the current release.
The releases would be distributed in several ways. There will be a "package universe" of all the core packages, and perhaps one of non-core packages, as well. There will be an update server so that people do not have to load new images to stay up to date. There will be a Montecello repository of all the changes so that everything we do will be repeatable. We will try to make it easy for people to use the release that is under active development.
Current members of the release team are Ralph Johnson and Edgar J. De Cleeene.
Reading it again, I can think of some comments.
The main one is that this is explaining what the Squeak team will do, which is to develop a process for making releases and shrinking the image. Part of the process is making it easy for other people to fix bugs and add features. I am not opposed to adding features! You could think that from this proposal. I just think that adding features should be what everybody does, not just the release team.
As part of fixing the process, a large part of my job will be getting people to participate. I expect that the social engineering will be more work than the software engineering. The software engineering is, in my opinion, very standard and routine, though I am sure I will get some argument about that. The social engineering will require more creativity.
-Ralph
_________________________________________________________________ Get the latest Windows Live Messenger 8.1 Beta version. Join now. http://ideas.live.com
J J wrote:
This sounds exactly right. Are you going to use Pavel's work? It sounds like he is doing a lot of what is talked about here.
I would expect that those with the most experience as to where we are now with the release process and where we might go next would be the current release team.
I would like to know what they think.
Especially because nothing seems to be as easy as it first appears. I cite my own attempts to load improvements to DateAndTime into 3.9 without upsetting the apple cart.
best regards
Keith Send instant messages to your online friends http://uk.messenger.yahoo.com
Ralph,
I applaud your proposal. I would like to take a moment to point out something to the community that I think you will agree with; but if not please feel free to respond with clarifications as to your own opinion if you think it appropriate.
I think it's time for all of us to really concentrate on thinking of the Release Team as managers and organizers rather than people who fix bugs and come up with new features and concepts. We need to all realize that the release team has enough on its plate simply handling decisions and keeping all the ducks in a row with the complex process of combining patches from disparate groups and verifying that the result is something that they can be proud of. It is up to the rest of us to spend time finding bugs, looking at others bug reports, submitting fixes, examining and commenting on these fixes, and working on new and exciting features for Squeak. That doesn't mean that release team members can't participate in this, but neither we nor they should think of it as part of the job of the release team or their responsibility.
Thanks,
Ken
On 11/24/06, Ken Causey ken@kencausey.com wrote:
I think it's time for all of us to really concentrate on thinking of the Release Team as managers and organizers rather than people who fix bugs and come up with new features and concepts.
Certainly. In addition to what you said, I'll try to recruit people to work on fixing bugs and encourage people who are coming up with new features and concepts. If I become the leader of the release team then I'll try to act as a focal point for people who want to get involved with developing Squeak, but I will tend to point them to someone else to work with rather than try to assign work to them.
-Ralph
squeak-dev@lists.squeakfoundation.org
-
Colin Putney -
Francisco Garau -
J J -
karl -
Keith Hodges -
Ken Causey -
Klaus D. Witzel -
Lex Spoon -
Ralph Johnson -
Sebastián Sastre -
Simon Michael -
Trygve Reenskaug