[Release] The role of Bob, Installer & Co.

Keith Hodges keith_hodges at yahoo.co.uk
Sun Jul 5 18:24:40 UTC 2009


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


More information about the Release mailing list