Keith Hodges wrote:
Andreas' proposal is to throw every package within the kernel and the image as a whole out to be treated as an "external package" to be hacked on by any approved person who fancies a go.
Really, the fundamental idea of the proposal to have a shared repository where I can collaborate with other Squeak developers on core packages.
The result can be viewed and used by anyone by publishing to MC and subscribing via an updates mechanism.
Correct.
The image will probably be a bit unstable for a bit, but we cant go to the extent of breaking it ever, because we are not distibuting a new image, just updates, everything must continue to work seamlessly.
Not necessarily. If there is a need to distribute a new image, we can certainly do that. I'm just not in favor of requiring a new image any time you want to do anything. Keep in mind that in previous messages I've pointed out Bob's role in building images based on the trunk packages. That's useful because people can fetch the latest version for playing with it which is right in line with the idea of reducing hurdles since the need to go through a lengthy update process can be just as bothersome as the need to download a new image every week.
In short: Updates and images go hand in hand. Yes, there will be images, and I would like Bob to play a role in building these automatically (say on a weekly basis).
Everything has to be done in small evolutionary steps as required by an updates mechanism. There is no mechanism for removing things from the image, or for changing the image structure. You will have to clear out stale package references, repository references from your image yourself.
All of this can be done automatically. Removals and doIts can be deployed (for example) via package preambles/postscripts and since the MCM update mechanism can be instructed to load precisely those version with the scripts attached to it you can utilize the process in a similar manner as preambles/postscripts in change sets.
Then it is supposedly up to Bob to take these packages as an **input** putting the image into an unpredictable state.
Actually, you start with some base image (like the previous release) which I think we can agree on as being called stable. Then you run the package updater process just like any client would. Not much difference to a SakeTask (which could be produced from the MCM automatically) and it leaves the image in a no more unpredicable state than loading any other code would.
Then Bob is expected to apply some fixes from mantis which were perhaps submited a year ago and were definitely not targeted at the image in which bob has to get them to work. Bob then uploads the resulting packages up to the trunk repo, Bob is now an automated contributor to the single trunk repository.
That's the point where I would hope that Bob can help us to drastically reduce the turnaround times. A fix produced a year ago should not stall for a year in Mantis. If Bob identifies the fix within a week or two, if Bob can prove that the fix doesn't break an existing test and does allow the provided tests to run then there should be little need to wait for a year. The point being that Bob's stamp of approval can help us screen tests that "look ready" much, much faster.
Bob also helps out by running tests in the hope that at some point in 2 years time, we get to a point where all the enthusiastic contributors to trunk have calmed down and have arrived at a reasonably stable working image. At which point a release will be asssembled manually by someone, probably Andreas, who will manually update the versions number, and manually ftp the new image up to ftp.squeak.org or publish an mcm for people to use.
Something along those lines, yes. I think that having an ongoing release team would be useful, for example to work out which demos should be included, how the contents is presented, which extra parts (fonts, media, etc) to include and so on.
Cheers, - Andreas
Andreas,
You have missed an important point in all of this discussion, that is that 3.11 was cancelled by the board over a year ago. Why? Because Squeak in its present form is reaching the end of its life cycle.
The 3.11 branch of squeak was reinstated by me because I recognised that there was a need for the community to consolidate and continue incrementally improving squeak (the pink plane was it?) while others are working on the radical new stuff (i.e. spoon, the blue plane) By consolidate and incrementally improve, I mean provide means for the forks of squeak to move closer together so that they are not irrevocably lost.
You seem to have persuaded the board that now we need to release a new image for the sake of it. If this is the case then we already have one...
Take an example SqueakLightII - there you have a new image, why not use it? What is wrong with it?
The answer is this... 2 things.
1. every thing that Edgar did to make squeak light possibly moved his fork further away from all the other branches, we have limited peer review and testing available to us at this time to know whether or not this is true.
2. The knowledge that edgar used to make his image is not available in a useful form to anyone else in any other fork, so this makes Edgars work yet another fork, as if we dont have enough already.
==
So in your scheme.... your process is different to mine.... your process is opposite to mine...
1. Every thing that you commit to trunk, is potentially taking the 3.10 branch further away from all the other forks. That is the big philosophical no no. That is the policy decision that you are reversing.
2 Every thing that you commit is a piece of code and knowledge that is ONLY useful in one place, and that knowledge is not useful to anyone else in any other fork of squeak. You are therefore defacto forking again. You are producing yet another image that the community has to maintain their code in, and you are adding to the problem not helping solve it.
Ok so you will end up with a new image.... but what is your new image good for that 3.10 cant already do? Probably nothing, so you are wasting yours and everyone elses time.
We might as well just all work on spoon or pharo.
My anger with Pharo is that they are doing lots of nice stuff, but they havent got any intention of making the knowledge availble to anyone else. Point of fact they are purposefully ignoring the public repositories for the packages that they are using and improving.
At least Edgar's changes to squeaklight are in a script and can be reproduced manually for anyone who wants to parse it.
==
Let me pick an example that you should be able to follow...
Lets say you implement ifNil: [ :arg | ] and ifNil: [ ]. What does this do that we couldnt do before... it allows code to be more flexible, and it allows us to load code that works in other forks, but not in ours.
You have implemented a piece of knowledge and who might make use of it? Yes everyone in all images. So the way forward is to offer that piece of knowledge to everyone in every fork, so that all images get closer together.
The more that the images move closer together the more possible that someone whoes code is stuck back in 3.7 will be able to move over to a 3.10 kernel.
When you institute you programme to have people working on trunk, you are making the problem worse, not better.
==
Lets give you 3 more examples...
1. I want to replace FileDirectory with Rio, if I do this in 3.12 who does it benefit. All forks because Rio is loadable into all forks. 2. If I want to provide a Logging framework for headless or kernel images to use, and I integrate this into 3.13, who does benefit. All forks because the package Logging is loadable into all forks. 3. If someone writes proper closures, which of the forks might benefit from it. All of them. So is our task to make a new fork with closures in it and then gloat over all the existing users who cant use closures?
So... as soon as you start working on improvements to the image, you are forking, and you are providing a moving target to anyone who is trying to make the problem better.
Please think again, you are completely on the wrong track.
Finally, Bob builds images, the deliverable he passes between tasks is images. What you want to do you can put in a cron task you dont need bob.
Keith
release@lists.squeakfoundation.org
-
Andreas Raab -
Keith Hodges